
welcome back everybody this is besides Las Vegas is the I am the cavalry track today's talk will be real-world security in a clinical health care environment hacking a hospital this is Paul Brandt and we're going to do a couple quick reminders one we are streaming on YouTube so go ahead and if you do have any questions go ahead and raise your hand we'll get the microphone to you okay to please silence your cellphone's we really do need them to be silenced if they're interrupting the talk that will not be good and security will not like it you won't like it either and finally we'd like to thank our sponsors especially our inner circle sponsors that's critical stack and Vala mat
valley male and our other sponsors are stellar sponsors those include lots of companies from blackberry to silence to the NSA and we wish to also thank all of our volunteers and everyone who comes together to help make this a incredible experience so thank you without further adieu oh thank you everyone thanks for coming in to my talk permitting you're actually in the talking meant to be and there's a lot of people here I wasn't expecting that but yeah thanks for coming out my name is Paul dant not Trant but it happens so Paul Dan I'm with a project called coated Hills we don't really know what this project does yet right now we just speak it at
conferences but what I'd like to talk to you guys about today is kind of some unique looks at unique ways of looking at a few security topics that I happen to feel are pretty critical and maybe we lose sight of some of these things because they seem too simple going from there to talk a little bit about IOT security some of the common problems examples of that I've been researching for about 30 years in security and I'm gonna go into that in just a second but really what I'm going to be presenting is sort of a culmination of a two-year long research project where we were through both surveying and of testing kind of assessing various
aspects of hospital security so not just med device and by the way this is not a med device security talk you're probably all relieved of that but we're going to talk about that a little bit but it really is looking at a hospital facility as just overall a basic system and finding ways to exploit the system like we do with any other systems so getting right into it as far as an agenda we're going to be kind of following along with these high-level topics if you have questions please feel free to raise your hand as they said and ask away and if I'm going too fast just let me know as far as learning objectives I'm not going
to read through all of these I imagine you guys will be able to download this slide deck some way through the event so you can read through these and I promise no more of these slides are wordy like this but the learning objectives that I wanted to just kind of set out really pertain to the the flow of the talk so you guys can of course go back and review those laters so introducing myself Paul dant I want to talk to you just a little bit about my journey in getting into this type of work how I initially became interested we all have stories like that how I made a career not necessarily on purpose but just kind of
things fell in place and then a little bit about what I'm doing today I wanted to establish some key kind of fundamental points as far as my belief system that are gonna kind of pertain to the whole talk and then I'm gonna talk very quickly about some IOT hacking and security concepts so I got started in security with video games my first role was the volunteer ethical penetration hacker for my middle school and you know they appreciated my work but what really got me interested in security was those that remember the shareware model when we were actually still distributing software on floppy disks but you know I could take these these games that I wrote in basic to school and sell them
for $5 and they'd have to pay me to get the little code and all that kind of stuff so you know it was really cool to get into that and have an opportunity at at age 2 start actually writing software and even trying to sell it but I want to talk a little bit about that and how that led me into security so just some sort of screenshots it's difficult to get screenshots off of a Tandy 1000 monitor but I started getting a bit paranoid about security when it with respect to software when one of the kids in school said hey my dad cracked your game and found your code I want my money back
and like how did how did you do that I kind of knew but you know fell into it because because of that so I started building my idea of copy protection and warnings into software and you know warnings like this you will lose all files at your own cost and then when we actually look at some of the code I'm doing things like just plain text values obviously this is tangental tangential and a way to the the overall concepts and concerns that we have today but if you really think about the idea of distributed software we got in my view a little bit spoiled with respect to security in the webpage as it's become more sophisticated we've had unique
challenges but with mobile apps being a very very large factor we're now back to the model of distributed software and actually being able to look at code sort of like this and find ways to reverse software get around security controls and that sort of thing so as I progress through the career through a career in security if you guys haven't seen this before I thought this was really funny but I kind of went right down the middle here is I think many of us probably have and avoided the convict part but it's led me to have the opportunity to do a lot of interesting assessment type engagements against places like nuclear facilities and film sets and school
systems and banks with a really unique focus on you know not necessarily hacking a specific system finding an exploit in a specific process or system but rather holistically looking at things kind of with it in line with the ideas of threat modeling and we're going to be getting into that in just a couple of minutes and of course the hospital security part that I mentioned is really where we're going to be focusing on as far as some of the latest projects that I've worked on and some of the interesting findings that that stem from that so I just wanted to throw a few key points out primarily just you know now that we're getting notices of breaches in
compromised pretty much every week now you know the media has has shaped things in a very interesting way that lead a lot of people to think that hackers are magical in some way and that maybe they sit down at a particular system and within 30 seconds like on swordfish can crack into it that doesn't really happen either so we also have the idea that a lot of tools that we utilize today threat modeling other processes for planning excuse me planning security strategy those work for attackers - and in analyzing systems and finding weaknesses Farfetch'd is no longer relevant or acceptable is something that I've kind of grown up believing because if you guys have had any experience with red
team exercises as you know a teen adults tend to not really want to believe that some of the things that you've identified can actually happen within their system so the idea that there's no way someone would think of doing it that way there's no one there's no way someone would find that we can kind of just throw that out for the most part and then any vulnerabilities that I might reference through this presentation they were all disclosed responsibly and we're not going to mention any any vendors today so one of the big things and I'm not going to spend a whole lot of time you know talking about security fundamentals with IOT but if we want to just pick
sort of a handful of problems that we tend to see with respect to IOT devices as broad as that is we see sort of a commonality in the way these these things are typically vulnerable large and diverse attack surfaces you know just take any IOT device that you might buy from Best Buy there's probably Wi-Fi ble maybe a camera all these things provide really interesting attack surfaces not even necessarily just into those components but maybe the rest of the system we see constantly the default configurations tend to leave the running state of that device not secure whether it's default passwords no passwords etc there's always an assumption with these devices that the the wireless or wired network
that the device is operating on is itself secured so there's really no reason to fortify the perimeters of our our system because the environment around it is secure we know that that's typically not true as well security design is something that I'm gonna spend a little bit of time so I'm just going to kind of bypass that but it certainly does factor into the way a lot of devices whether it's consumer devices or otherwise that have greater consequences with with respect to security we typically see that there's just not a lot of security thought in the design phases and this is nothing new of course but the idea of bolt-on security especially doesn't work with devices
that might be plugged into a patient or a car and then lastly the binary protection is something that is almost always missing with respect to devices that allow us to actually pull software off of them and analyze them so there's been some research I don't know if you guys have seen any evidence it's kind of all over the place but looking at a lot of mobile apps from just public app stores across various verticals like financial services and just doing kind of the five-minute static analysis type thing that you would do on an iOS or Android app and we're seeing like you know like 97 98 percent of these apps have no attempt whatsoever at any sort
of binary protection despite the fact that they're readily available for analysis to really anyone that's interested I lose it okay so kind of bringing those same concepts back I wanted to kind of frame the idea of what we're talking about when I speak to IOT devices I'm sure everybody has ideas in their head of what we're speaking to but in this very generic scenario you know we have our kind of home automation type ecosystem and when we when we put all of this into perspective where we're looking at these things as independent systems as well as interconnected systems and then apply these principles that's pretty frightening and again that's nothing new as well but we tend
to I think as a whole people who are trying to solve these problems sometimes get a little bit paralyzed by fear when looking at such wide and also deep problems and concerns with these products devices etc you can couple that also this diagram is supposed to represent a cloud or cotton balls but the idea of course is that even outside of a residence or a business all of these devices can also be connected to a whole bunch of other devices in the cloud or what have you so that kind of just compounds the risk as we continue to see these same security vulnerabilities remain pervasive throughout these types of devices and so I want to talk a little bit about the
idea of designing security in not that it's difficult but you know sitting down and designing a product we all know that the primary focus is going to be on delivering functionality as soon as possible and iterative improvement and all of those types of things but when we really take the time to sit down and think about what it means to design security into a system we start to kind of understand more where some of these concepts like security and quality intersect and how these systems are should be developed and thought about this is probably pretty clear but products are systems so they kind of go together I'll use them interchangeably but the idea is that we
talk about products that are available to consumers they don't come with any you know in-depth warning information hey you should change this default password and that you know that leads to to a lot of challenges we'll get into some more of those but and then the last thing we're going to talk about here is kind of my idea of threat modeling particularly when you want to use it against the system kind of reversing the threat modeling idea and how we can apply some of the simpler concepts to that process and maybe get value out of it whereas and you know certainly not making any assumptions but a lot of the organizations that I work with from a
consulting perspective you know tend to just not even know where to get started when it comes to threat modeling when you have Microsoft's models and all these different nomenclatures it becomes overwhelming so I want to talk through a few principles that I've kind of adhered to that I think make that exercise a lot more straightforward so Before we jump into that I made reference earlier to quality and I know everybody is familiar with this but it's always fun to just remind everyone how much issues cost to fix in production we know that that's really where all of our cost is is going in terms of fixing bugs that made it past a certain phase in the SDLC so if
we kind of think about that from a quality perspective it kind of goes without saying that software quality software can be secure software not necessarily but the two definitely play a very they have a very cohesive relationship I'm gonna jump past that and so when we talk about just step by step threat modeling there's lots of examples I just kind of pulled this one there's plenty of variations and permutations of these steps but the main idea is kind of remain and those main ideas are the ones that I found typically get sort of lost in the rush when trying to and really develop solid security strategies that make sense for what we have and what we're hoping to build so
to talk through this really quickly I'm sure a lot of you guys are familiar with this so I won't spend a lot of time but you know there's a few key components to a a threat model that is is effective and actually works assets guys know what what we're referring to with with respect to assets understanding where within the system those assets are going to sit and obviously we're speaking very generally here and that's that's kind of the idea we don't want to get too deep too quickly and miss the things that are pretty readily apparent like I said getting kind of lost in the details from the very start we want to avoid that so
something else that when I work with organizations I find is a lot of times missing is good updated documentation on the system and that could mean everything architectures for you know Network data flows or even just how the software was built what it does why it does it certain ways if we had that knowledge collectively not in people's heads but somewhere that it could actually be used and we're achieving this certainly things are getting better but if we don't have that overall understanding we really can't possibly think that we could effectively secure that system if we don't really know ourselves how it works and it sounds very simple here but when you sort of extrapolate that to you know a
multinational project where you have teams upon teams upon teams working on this stuff we see a lot of that happening the collective knowledge is strewn throughout different organizations different document systems learning systems and all that stuff and again it gets lost so not that I'm trying to preach to you guys but just something that I've found along the way plays a very big role in understanding how to secure a system and then decomposing the application or the system classic problem solving that we're we're just decomposing the problem as much as we can identifying components in the blocks of the system how they work together threats I don't want to really go do a big talk on threats and all the
different ways that we interpret what a threat is or threat agents and this stuff but it's definitely a part of the system it's probably one of the more difficult elements of a threat model to really sit down and effectively brainstorm without going on kind of wild tangents but what I've always found and I'm gonna get into this I think in the next slide but when you decompose a system in order to develop the understanding that that I'm kind of describing from an architecture perspective some of the vulnerabilities or maybe places where an attacker would look to attack threats in a sense they kind of start bubbling up to the top as your understanding improves as the
overall architecture gets more in line accuracy wise with what is actually out there what attackers are actually looking at so I found this I can't take credit for this but I thought this was a really good way to sort of bring all of these these ideas together culminating something that I hadn't talked about yet but so if we look at Bruce Wayne and Batman threat model and the things that that he's concerned about Batcave and Alfred these assets of course have different values to Batman maybe not all the same but we also know that Batman has threats the Joker etc so the part that I haven't really taught spoken to yet and this is really fundamental to
taking the output of a threat modeling exercise and applying it to your strategy applying it to budgeting for for security spend but the protection the the controls and and other security mechanisms that make sense for this system with respect to the assets and the threats that are targeting them so very simple but I think quite meaningful in terms of how all of these things fit together and how we could apply it to something a lot larger and of of greater consequence and before we do that I I wanted to talk about just some things that I've kind of taught as I work with organizations and teach classes etc but I've always found that classic video games taught me a lot
of really interesting security lessons probably didn't realize it back then but looking back I think it's pretty cool so I wanted to show you a few of those but if you guys remember shinobi Megaman these are awesome games so let's talk about shinobi if if you're not familiar with shinobi you play the role of a ninja and you fight bad guys and it's a platformer and of course every level has a boss and the boss is different in some way so if we just kind of consider ourselves threat modeling this particular boss we start to break things down from an architecture perspective so loosely you know what are the assets well the asset is the guy's head that
we're trying to to shoot or or hit we can identify areas where attacks are ineffective and of course that's a part of the the whole idea of playing the game and winning but if you really apply that to how you would typically look at say an architecture diagram and you're starting to look for we might refer to it as low-hanging fruit or obvious weaknesses the same principles here and I've always found that this can can really help simplify understanding some of those those ideas Mega Man 2 I always thought was really cool if you're not familiar with Mega Man the whole idea is you get to pick a different robot to fight and they all have different powers
and abilities and if you defeat the robot you get that robots weapons and what makes the game interesting is that each boss has certain weaknesses to other weapons and as the player you have to kind of figure out how to do it so if you think about you know sitting there with Metasploit or it really anything where you're trying to actually run an exploit and it's not working Mega Man kind of follows the the same idea that repetition is key and it's also pretty relevant when we look at threat modeling as well we didn't talk a lot about the threats within the threat model but motivation is obviously always a factor when we're weighing risk of a
particular system being attacked by a particular threat and a lot of times that motivation is displayed and how willing you are to just keep trying harder and harder until you're actually able to exploit successfully gain control etc and then lastly this this is definitely a stretch but I just wanted to throw it in here but detecting timing attack opportunities based on games like punch-out so if you played punch-out the whole thing is you're a boxer and every guy that you box has a little like timing tell some of them are very subtle some of them aren't so subtle like I said it's a stretch but the really cool thing is it's sort of indicative of some
of the things that we can do when we're testing for timing attacks like the classic authentication timing attack you know if I provide a valid username and the wrong password how long does it take to return that versus if I provide an invalid username and a password obviously if if we start monitoring those various timings we can start to see where where things are maybe where things are happening and where we might be able to inject fault so yeah I I thought that was going to be a lot funnier than it actually was but thank thank you for indulging me so let's just come back to the threat modeling thing here and talk about how we would apply
that to something real and then we're gonna talk about hacking a hospital so if we look at just going just a generic system architecture this is I think maybe the various systems involved with hotel guests checking in the front desk people doing the cards all that kind of thing all the databases all the web servers and if we just kind of generically use this as our understanding of how the system works at a very rudimentary level we can start to kind of focus in and build paths around and this is further in the threat modeling concepts but the idea of trust zones trust boundaries areas where we see communication between systems and there's effectively an inherent trust at
least the way the the architecture is designed when we start to understand those things that's when we can actually start to kind of like what we did in shinobi see potential weaknesses in in the particular system whether it's interfaces network interfaces physical interfaces just areas that look interesting and most likely to to yield something interesting and of course once we've we've done that exercise and maybe we take this concept we run tests against the system to to confirm what we we think we found and we're going to come up with a list of not necessarily vulnerabilities but suspect vulnerabilities potential vulnerabilities and that's really how an exercise like like this would would be carried out we'll start tackling each
one of those potential ways to exploit the system and then we typically end up feeling like this when someone breaks the system and we didn't think they were going to be able to okay so getting two attacks in a clinical environment in this case we're speaking specifically of a hospital we're gonna talk just kind of about the the exercise how we planned it our overall objectives what we did to enumerate targets etc and then ultimately how we ended up winning so if we start with primary objectives of the exercise and again this was done in in concert with the the facility it was there was very limited staff knowledge but in general this was as real-world as
we could make it and obviously we weren't testing when it gets down to actual devices and systems we weren't testing anything production or hooked to a patient so the primary objectives of the exercise disabled patient vitals monitoring mechanism in a specific patient room so think about what all of what that means we have to identify the patient we have to identify the room we have to find some way to influence and disable the patient vital monitoring system and you guys all know I'm sure what I'm describing but all of the things connect to a patient in the band it goes to kind of like a hub and then you have the displays and the nurse's station you have displays in the
room and all of those things of course are capable alarming if any of those vital measurements change at a certain rate go within out certain thresholds etc so there's that and then we have to prevent reenable of that mechanism until notified and and what we kind of envision here with being notified is we are kind of playing out a hacker for hire scenario so you know we don't actually want to kill somebody in a hospital but if someone wanted to pay us to disable some systems so they can kill them well you know that's that's kind of a different story so we were kind of playing playing that scenario out ensuring no direct or indirect alarms go
to staff members of course we would have to understand rotations with nurses doctors that sort of thing that's basically just a matter of sitting within the hospital and watching out so all of those things can be aligned to make sure that whatever is actually happening once we disable the monitoring systems can actually take place in that room so as we started serving physically looking for interesting ways that we could maybe get network access make that network access persistent maybe escalate there were a few things that that really stuck out and of course you know this this scenario was really targeting a specific facility but we found these sorts of things at the facilities we looked at so going
through some of the interesting ones now I'm not gonna sit here and say that we were able to do bad things on a hospital network from Starbucks we were not but what we did find is that the Starbucks in the hospital Lobby offered free wireless Internet access and there were Hospital production systems that were at least pink able from that wireless network we let them know they weren't pink able anymore we don't know what they were but you know that's interesting so yeah internal IP yeah the question repeat the question yes please oh yeah I'm sorry the question was was that internal or IP route or Internet routable yes yeah so all internal systems you know obviously
there was some access control within the the ingress for the wireless network into the to the Starbucks wireless network so I don't think necessarily that could have been used anyway I'm confusing myself but yeah they were internal systems as I said we didn't really work to identify them we wanted to just let the staff know but that was really interesting and I think could be had we not notified them and just played that out that could have also led to some really interesting things the patient and vendor kiosks that were placed throughout the hospital were also really important there's you know there's interesting things with these kiosks and and various attempts at kiosk mode and constraining the user interface
and it doesn't always work that well especially now the things are touchscreen and you can just hold your finger down to get the context menu to pop up and they never seem to anticipate that but that's actually what we did on on both patient and vendor kiosks we use the vendor kiosks to basically go sort of back to past vendor check-ins and we could print their badges out so then we had legit credentials to be walking around the hospital the patient he asks actually is is where we established persistent Network access which which was surprising but turned out just to be a window systems running in kiosk mode and they weren't too difficult to bypass and that gave us a
network access point and what simplified it a lot for us is they going through just kind of over high-level discussion there were maybe like two hundred and seventy four VLANs throughout this hospital and it was all completely wide open completely flat so a patient kiosk has as much access to everything as anything else does and we let them know about that too and that was something that they addressed pretty quickly but nevertheless now we have our persistent network access and we were able even able to to utilize the the windows would help me thing where you can let somebody remote access and so we got remote access inbound into that patient kiosk and that's really what let us start
looking at some of the systems that we were more interested in to accomplish the primary objective without necessarily being stopped so if you recall back in the primary objectives we have to disable this particular device in a specific room for a specific patient that obviously is going to retire require some trickery we we looked at social engineering aspects but none of us knew enough about medical stuff to you know be able to talk to a doctor and/or a nurse and get them to give up the information so on the flat network we found all of these multifunction printing printing devices faxes etc the same brand essentially the same model used all throughout the hospital including patient intake
surgical etc so this particular device actually had this really nice document cache where it would store anything that was fax through it inbound outbound and the default configuration didn't require a password for that document cache so we actually found a treasure trove of pH I just kind of wide open but to our advantage that's how we got the information for a specific patient and now we didn't actually at the pH I of course so we just made the assumption okay if the patients in the hospital we would be able to identify them and probably get the room number so we've crossed that part off of the list as well now though the the big part of the the primary objective
disabling the monitoring system this is where we needed to persist in network access so we could really start working on this particular system and in with all transparency it was a production configured device but not on a production network of course it was put in place for us to be able to test but aside from that that's where those were really the only exceptions made to make sure that you know we didn't actually hurt somebody so this particular monitoring system was a linux-based kind of what you would expect from IOT the types of IOT devices you're gonna see in hospitals lots of interesting physical input output ports running Linux hasn't been patched since 2009 so you guys were in the shell shock
family of vulnerabilities I mean this was like vulnerable to all of them so not hard to get root on on this box you know they have this lightweight web server just a lot of the things that that I'm speaking to that I think we all agree are pervasive throughout a lot of the the IOT connected health connected auto stuff that everybody is getting into so through a variety of research I'm sorry reverse engineering getting around some some interesting file integrity monitoring like watchdog processes we were able to tamper with the software and basically disabling it outright was was difficult because it's always sending data to these other servers so instead we found a way to
just take a cache of the data and replay it so that we kind of cut the input off kind of like if you want to rob a bank you know you just loop the camera feed we basically did that with the vitals and so at that point we actually had somebody connected to the monitor the the finger pulse all that stuff and we removed all the sensors and it just kind of kept on going like everything was fine so in theory you know after that happens we don't really know what is going to go on with the patient an operative can be sent in take the patient out depending on the rotation of the nursing staff you
know that could go undetected for an hour and a half hour 45 minutes so yeah all of those things together allowed us to achieve that overall set of objectives which we weren't too surprised about we knew we would be able to do it but we just didn't expect it to be quite that easy and so you know there was a lot of work with various vendors the printer manufacturer that was involved sent some technicians in disabled all those document caches so there was a lot of good that came from the exercise other than just you know being able to tell really scary stories at conferences and shows but can I get a time check guys okay cool
so with with all of that said now that we're kind of really thinking about what you could actually do in a truly coordinated planned funded attack against a healthcare facility if we kind of go back to just the general idea of IOT devices I wanted to talk about something that's kind of unique to kind of unique to them but Bohr attacks break once run everywhere I'm sure you guys are familiar with these but those and other pervasive mistakes make hacking IOT really interesting because any of the exploits that we might be able to carry out say to find cryptographic keys other secrets what we see with a lot of these devices is that those cryptographic keys are the same on every
single device so if we've cracked one device we've cracked all of them now that's not the case with all metal I Oh T devices of course but quite a few of them I mean if you think about it from a manufacturing and it's just an overall poor and perspective it can be challenging to to automate that sort of thing so that there's there's an actual per device level of some sort of security so as we kind of continued researching if you guys are familiar with the the IOT hacking village at DEFCON I had been running it for the last couple of years and that's really where we saw a lot of interest in and bore attacks and kind of
applying them to the other sorts of IOT devices that are available for consumers like smart fridges and all those sorts of things so with all that in mind if you guys haven't heard of showed an it's a really interesting tool it's not new but you can kind of think of it as like a search engine for IOT devices so if let's say you wanted to look for rico multifunction printers in showed and what it's going to really provide is based on whatever you're looking for in terms of keyword pattern etc it's gonna find devices and enumerate basically everything we need to know about them so if I am you know just looking at I'm sort of a not so targeted attack that's
pretty easy but I can also really dive in and start targeting specific organizations so looking just for Rico a brand of printer in the US you can see well maybe you guys can't see that but so telnet is the top service identified for all these devices the top organizations are AT&T and cogent level 3 Comcast business and so basically these are just printers that are sitting on a network that somehow is allowing access from the outside world with really really vulnerable services still running like telnet FTP is one that we see quite a bit sorry about that so this particular device it enumerates the ports and then we can see pretty instantly how we can
exploit these vulnerabilities and get into the system and to make it even even even easier excuse me sho den has an exploit database so that you can actually search for specific types of devices specific vendors find those exploits and then go back to your listing and just start hacking them so what we what we have found to be really interesting in in doing workshops and stuff with various IOT device manufacturers everything from like lighting companies like enterprise office lighting those systems are really complex I hadn't seen them before and its really interesting but as part of just a security workshop with them we encourage them to start looking for things related to their lighting devices
using showed an and right there live in the in the workshop we start looking it's like oh yeah we know that customer so we click on the device and there's the the port that's used to basically log in to these devices and we tried the default password and we got in like it was shouldn't have been but it was eye-opening for that for that organization and you know it goes to something I had mentioned previously especially on the consumer side of IOT when consumers that are unaware of this stuff continue to be unaware and use these devices our exposure just kind of continues to compound and and that I think is why organizations you know tend
to not look at tools like show Dan maybe they don't really want to see what is actually happening I think that's that's always valid but you know it's just it's overwhelming and it brings to mind who's really responsible is the lighting system manufacturer responsible for notifying their users of all of these different types of risks inherent in using their devices is that the consumer or the buyers responsibility to understand what those risks are we don't really know you know we can put warnings on packs of cigarettes about the risks there but when we're actually talking about potentially exposing sensitive information to anyone there's really not a lot of awareness on the part of vendors etc so kind of in summary where
I'm going with that is tools that can show us just how pervasive those types of systems are become really useful for attackers of course but also for us so yeah if if you have some time definitely check that out if you work for an IOT device manufacturer really check it out and and see if there's anything interesting that could be maybe exposing your organization okay so we're wrapping up I'm not going to read these either very much like the learning objectives at the beginning but what I really wanted to just close with is the idea and I know that you've heard this before it's somewhat cliche but when we approach security planning developing strategies exercises like threat
modeling I mentioned before that there's a there's there's a lot of opportunity for paralysis by analysis becoming overwhelmed I think we in general as as an industry have started to really feel the weight of that and you know whether it's just renewed looks at some of these issues new paradigms that may be where we're trying to move into we just have to continue to combat what is typically happening in organizations where we just allow security planning to become a bureaucratic process that really doesn't produce anything we can get around that and my personal belief of course is with everything that I've described today is that looking at these things and a much similar I'm sorry in a much simpler way
than we tend to today can really yield a lot in terms of how to proceed forward and actually start securing things based on the value of the assets based on who what is likely to attack those assets so spending intelligently is ultimately what we're really talking about so that's all I have thank you guys there much for your time sorry about the video game thing I really thought that was going to play well thanks guys and we have time for questions oh yeah I always forget that if you have any questions go ahead and pass the mic to you I did like the video game thing questions not statements on your slides it looked like
you had some kind of physical reconnaissance perhaps to get your maps or to get the physical locations of things in your maps I'm not sure can you talk about that sure yeah that map actually came from Google just as a you know hypothetical because at the end of the day the these facilities are all yea laid out the same did I yeah that was all physical reconnaissance for sure yeah can you talk a little bit about how you did the persistence on the kiosks yes so once we were able to basically I mean they were the patient kiosks were Windows systems so once we were able to get admin on that we just utilized and
then the name of the actual services is evading me but it's microsoft's built-in windows tool for remote support for actually allowing someone to access you know inbound and you know all we did was just tunnel the traffic over something that could actually go out and come back in and we had pervasive network access question about the I know you had a primary objective of trying to disable a specific target but were you able to get ahold of the or have access to the electronic medical record that's a good question I'm just given the objectives of the exercise we weren't too concerned about that we did find that you know like a lot of systems that are storing
records that people need to access there's extraneous ways to access that data so lightweight web servers of course so I think the answer is is yes I mean we we felt that those systems are likely exposed as much as some of the other systems that we involved in the attack but we didn't actually look for that specifically but given it was all right there on the printers you know it's reasonable assumed yeah you say how long does it take you to get all that access [Applause] probably about a year yeah and that's not so much because of you know us taking a year to figure it out just some of the the planning and continuous
approvals needed to keep moving with the exercise but you have a clean version of the report that's can be published or is being published yeah there is actually one that is published I'll I'll get with you after in the medical space one of the one of the reasons that we hear that it's so vulnerable is that systems can't be patched you have to have at the approval on and on and on and I'm wondering about what you're finding that facilities are doing for mitigation are they going to micro VLANs or you know are they are they completely isolating systems so that they're not I'm not internet accessible or can you speak to that at all sure
yeah that's that's a good question and a lot of it yes they're trying these things but you know when you haven't even figured out access control for you know the basics of your land they're they're falling behind and so we see the the normal constraints and budget and staffing and it that's what's presenting these these facilities from moving forward with strategies like that what I'll also say though that makes these things challenging these devices especially when they're not being updated properly is that from a network access perspective you can try isolating it all you want but they have physical access ports including an Ethernet port so you know all you really need to do is
it literally find out the right color bracelet for that day and you've got the whole Hospital at you know you just walk find an empty patient room and you know if you're willing to run the risk maybe spend 20 minutes plugging into it and yeah so that's that's a big challenge to its physical access just to clarify on the comment over the previous person who was asking medical devices there's a myth that medical devices cannot be updated for that the FDA is changed that it is now a requirement of both the vendor and the hospital to update those medical devices we wanted to make sure that was clarified and on the video before I asked my question right my
question is is that this medical device do you know if it was recalled or not because there are a lot of medical devices that have been recalled but are still in use in hospitals and you mentioned that the firmware was in 2007 I believe 2009 it was Gentoo Linux yeah okay and usually it takes about five years for a medical device to go from production and usually that means that it was frozen for five years at which point it should be updated no yes so probably came out 2013 and has been out for about five years or so so I'm just curious if you had had a chance to check to see if it had been
recalled or not or if there are any types of FDA notices on it sure - yeah I'm not aware of a recall we certainly had some conversations with the vendor they were actually aware of most of the vulnerabilities that we identified in the exercise already and yes so to your point the the challenge with keeping these devices updated it's you know it's it's a challenge just in terms of the work that's involved the access that's required the organization that's in place to properly distribute updates yeah that for a comment to build on this the postmarks or the purple he's also here the post market basically says if you have a vulnerability obviously we want to tell the vendors but for their
sake if there's an unmitigated pathway to harm they'll do a safety communication so a lot of times vendor wants to handle themselves and we usually encourage you start there but the process is supposed to work that when you kind of find something with an unmitigated pathway to harm something should happen agreed especially if they were already aware of it yeah and the Suzanne has seen a variation of this talk yeah we've we've awesome looks like we have one final question here this is a little bit of a basic question but if we were to look at the IOT devices and and as in barring the physical access to the Ethernet port question if we were to say that all the
IOT devices in question they're only communication was a call out to a well known address how much more how much harder would your tasks have been so in others they would not accept any inbound connections at all it's only outbound that they initiated hmm well so assuming that the functionality isn't impacted by you know that constraint yeah it probably would have made it more challenging that the main thing is you know if we're not getting physical network access we could otherwise get physical access to the storage in some way so when the software is actually making calls out to known addresses etc that really just becomes a matter of analyzing the software and tampering with it you know to change the call out
to change the list of known addresses that sort of thing so that would be the approach there makes it more difficult but as long as we can get access to the binaries that are running on that device we can bypass most in our in my experience I don't know why I keep saying we an hour but in my experience most of those controls can be bypassed thank you very much Paul thanks guys [Applause]