>>Thanks for skipping out of Kaminsky's talk and coming to see, see us, we really
appreciate that. Um, just want to introduce ourselves quick. My name's Scott Erven, I do run a
company called SecMedic and have been involved in IT security for just over 15 years, with a focus
probably the last 3 years on medical devices and security so that's who I am. You want to hit
me up on Twitter, you can try that or maybe get a hold of me after the talk and I'll give you
contact info. >> Hi everyone. My name's Shawn Merdinger and I've been in security for about
a little over a decade now. Worked at some big companies doing healthcare, I'm sorry,
doing product security and then moved into some consulting and now I do healthcare and someone
told me they were gonna save my spot at the summit party, so it's still, the line is still
going, I think. (Laughter) So hopefully they'll hold it for me. God, I thought that would
get a laugh! So I also run the MedSedic LinkedIn group which is on LinkedIn, it's got about 600
folks. Anyone is welcome to join and then I have a little Twitter account here too which is
focused on technical issues with medical devices and healthcare security in general. >> All
right so first off we want to start with, you know, why we did we get involved in research in
medical devices. Are we just assholes that want to call out people or do we really have a
vested interest in this, in seeing that our products are more secure? So one of the big
things for us, you know, we realize that healthcare industry is behind and this isn't just
another Android bug when we get into these things. It really has patient safety consequences with
these types of devices. They are made to save lives, and ultimately they do a very good
job at that. But we think that security can get better, can improve. And so that's why we
are looking into the research on that. And we also, we know there is a lot of healthcare
organizations that this is kind of new to. As an industry healthcare security is quite a
bit behind. We'll talk about that later. But we want to equip defenders especially in the
healthcare space and make sure, you know, that they can protect those devices and ultimately if
you look across, you know, any healthcare organization out there, I think if you are
working for one, you're gonna find something inside of their missions and values, right? And
this is what really got to me of how can I, you know, affect missions and values for
healthcare organizations? And they're going to have something with, you know, patient safety,
is going to be something, one of their critical missions, one of their critical values or core
beliefs that they have. And so that really came to me is: How can I have a direct impact on
that instead of sitting in the background, you know, as a security guy and kind of
indirectly being able to help folks out on the floor deliver patient care? This is where we
cross into, you know, IS security folks really having a direct contribution to that
mission on patient safety for organizations. So it's kind of what we're doing, you know, why
we do it. >> One thing I'd add, too, is I think we have a shared commonality too when it comes to
healthcare and medical devices so no matter who you are, no matter how spooky you are, you
know, what kind of surveillance you're doing or afraid of, we're all human, we all get sick, we
all get people in need of healthcare and I think there is a truly shared commonality of,
you know, when we check into a hospital, when we go to a clinic, no matter who you are,
you want to make sure that that device has some integrity and that you can trust it. So real
quick, I wanna get into some of the disclosure, too. We just want everyone to be aware that
the stuff in our talk has been disclosed and we'll talk about some of the more detailed
disclosure processes as we go along. This is kind of a high-level time line so as you
can see, we are working really hard to push our research quickly and we are pushing
really hard to get it out quickly to the community and especially the healthcare
organizations that, and medical device manufacturers that can really make, you know, make a
change here. So April 30th is when we went into this SMV finding disclosure that we're
gonna talk about here. And that was the first time we disclosed this information at DHS. We had
a detailed briefing with them about a week later. And then we went into after the SMV stuff we
decided to look at direct, public-facing internet-exposed medical devices and
infrastructure and some of those were then disclosed in May. So again it's really recent stuff
we have been working hard to get the disclosure process, so we could talk to you about it. We
have also been providing a lot of ongoing assistance to both federal organizations as well
as, you know, healthcare organizations and manufacturers as we work through these things
with them. So... >> So if you are looking for zero days, you are in the wrong room. So that's
not how we do this. We try to be really responsible in all our disclosure and all of our
communication with this. We don't want to put people at risk, there is already enough
risk in these devices that you'll see as we get further in the talk. And that leads into
many of these vulnerabilities are old, in many respects this is a new area, for medical
device manufacturers, and this type of exposure because of the integration that's happenings
across healthcare with EHRs, going all the way to the bedside, there's gonna be new
pacs surfaces that emerge. So Scott did some really great work on threat modeling with uh, and
he'll demonstrate how it's a very simple vulnerability was leveraged to impact potentially
from an adversarial standpoint an entire organization, including their medical devices.
So that should be a real wakeup call. I was a little scared about talking about that at
first, more because it's such a low-level vulnerability but then he-- >> Woo-hoo! (Laughter)
(Applause) >> Let's rock it! >> He--, I didn't even say cyberyet. (Laughter) Then, so
the other thing is the medical device exposure from the public Internet. So as I mentioned more
of these are coming online, there's greater integration and there are medical devices on the
public Internet. We are trying to be responsible in disclosure but at the same time creating
more pressure to an awareness of this, too. . >> All right. Taking a timeout here. >>
Excuse me. (Pause) (Laughter) Raise your hand if you are a brand new speaker at DEF CON.
>> Let's go! >> All right. Welcome for the new speaker! [Cheers and applause] >> All
right. All right. Solid. >> God, that's just awful! (Laughter) >> So these
external findings pose a significant risk -- (Laughter) -- >> I'll work this a little
more. >> You guys are done! >> All right. Yeah, so what's the bad news here, right, in all the
findings? The external findings we're gonna expose, you know, we think it is a significant risk,
the patient safety. The medical devices, the supporting systems and technology that interface
with these medical devices. The other bad news is most of these we found within 30 minutes to an
hour, so you know I'm not up here to tell you I'm some elite hacker or anything like that,
there's much smarter people in this audience and we'll get into how you can help, you know, get
into this area later but it was very simple things we did and threat modeling that we did here
but they are definitely significant threats to patient safety. They also provide
support, the healthcare industry is very far behind other industries, typical of what we
see in, you know, financial or retail sector which they are getting breached every week as
well so there's not much difference but it's not just your bank account. It is, you
know, patient safety issues here that are affected. I think in our work, you know, one of the
things that is coming to light, and you know the folks over at the agency, DHS and ICS will
probably start to tell you now, we always thought industrial control systems and that whole
industry was quite a ways behind what we are seeing. But I think it's safe to say now and with
the research that we're showing, that the healthcare industry is probably five years behind what
that is. So it's definitely a good ten years, we've got a lot of catchup to do and we probably
need to do it fairly quickly with some of the mobile health and digital health stuff that's
coming on the horizon which we'll touch on later, but. That's definitely some of the
bad news. So let Shawn cover the good stuff. He can be the good guy. >> Yeah, for once. You
know, one thing I'd add, too, with the, it's almost like a lost decade going on here, so,
with medical devices. And also healthcare security folks are amongst the lowest paid in the
industry so that vertical itself, which is I think will actually change in the coming
years, because there's going to be more breaches and there's going to be more specialized
expertise which is needed with these devices. So, yeah, there is good news. The external risk
can be mitigated using your existing infrastructure in many cases so you want to follow
those hardening guidelines that are put out by like MIST and other organizations and CSI,
right, too? Didn't we talk about that? CIS, rather. >> Yeah, CSI is a TV show. (Laughter) >>
Thank you, I'm really not a drinker so this is already getting to me! Damn goons! >>
So, yeah, CIS, you know, they've reached out. I think we'll talk about it a little bit later. >>
Ok, yeah, we'll do that. >> Bear with me. (Speaking off-mic). >> So just a show of
hands here: Who has heard of SHODAN? Oh, that's good. That's encouraging. So, you know,
SHODAN was one of the main tools that we used in this and that's a tool you can leverage in your
own organization and John Matherly, props out to him, this is his project and so, you know,
with using those types of tools, you can discover what types of exposure you have on your
external network and then you can start doing that mitigation. >> All right, so I just want to
touch kinda quickly before we get into, you know, some of the new stuff here, on, you know,
previous research, more so, you know, previous device exposure, you know, across platforms, the
type of things that we see, the types of issues in these types of devices, so first is kind of
lab and refrigeration systems. So that environment -- and a lot of these, they are not unique to
a vendor so there is no value in saying, oh it was this vendor or it was that vendor, it's really
across platforms. It's a systemic issue, it's not, you know, one versus the other here.
So we'll talk about them generically and kind of give you some architectural background
into how these things function, where the flaws are in these devices where an attacker could
potentially, you know, cause patient safety issues. So refrigeration storage, these are
anything from, you know, storing just blood inside the laboratory all the way up to like full
cryogenic like freezer levels. The types of issues we see on these are they have unencrypted
web services and they have hard-coded credentials. So the lab techs inside the healthcare
organization, they'll actually carry, most times, sometimes they'll throw it in their desk,
but usually they'll carry pagers that are set up to alert them if there is like a upper or a lower
limit on these devices that gets tripped. So if it loses power and the temperature drops they
get alerted so that they can go respond and they can throw it into another, you know,
refrigeration system. Well through these web interfaces, which either have no
authentication into them or they very weak credentials into them, you can go into those types of
systems and you can alter things. So first you can turn off alerting or change the
alerting to those pager systems. Secondly you can change upper and lower limits on the
temperature controls. You can even shut these units off. So those are the type of risks
there, you know, spoilage, things like that, that you get into with those devices. Pacs
imaging. You know, that's not really a patient safety issue too much but this is where
you're seeing when you get into like the PHI stuff, not necessarily patient safety, but
this is where I feel a lot of the exploitation of actual patient documentation is coming
out of healthcare organizations. All but one vendor that I researched on the paces imaging
side, how they operate is through an application, through that pacs application they call
back-in storage for those imaging systems. Through the application they actually prompt
and they use authentication and they call it and they log if you've accessed that PHI. The
back-end storage unfortunately happens to be in all but one case that I've looked at
completely unauthenticated access into the Nas device or the storage network where all of
those, you know, patient records and images, and, you know, PHI type information. So that's a
big one. I think we'll loop this Pacs thing back in later when we start talking about some more
exposure and how I believe, you know, a lot of our data is being leaked out very easily outside
of healthcare organizations to sell people's medical identities. >> MRI and CT
systems, you get into like nuke med systems as well, these are interesting. They pretty much
function similar across the board when you get into CT, MRI systems. If you look at all the
documentation you'll find that there isn't a whole lot of difference on them. Nuke med
machines, they actually have work stations that directly talk to it but when you get into the
radiology space, the MRI, the CT, that's when the RAD tech is actually sitting in the room
behind the, you know, behind the enclosure and how those operate is obviously the physician
orders what imaging they want, and they program that order into the application and that
actually gets sent down to like the CT system. And so it kinda sits there in like a holding
pattern. It almost functions like a queue inside those devices. But unfortunately they
use unencrypted web traffic as well so you can man in the middle that traffic, you can,
you know, alter those types of things. They do have a failsafe which is actually really good in
most cases. Like the nuke meds are direct and they don't function like that but that's
not real radiation exposure. But MRI and CTs, they kinda have like a Staples Easy button over
at the side where the Rad tech actually has to, you know, manually kind of hit and then it
goes out to the work station and takes that queue and then processes that image. But
because it's unencrypted and you can man in the middle of it, you can alter what's actually going
on in there when they actually execute that. Defibrillators, this one's an interesting one,
when you get into ICD technology, if any of you know who Kevin Fu is, he did a lot of
great work, he actually documented it out. And most of these, they run, they run on
telemetry so they run at like a 400k range. The problem with these is the pacemaker
controller systems, if you access those, they don't require authentication. And once you
associate it to the implantable defib, you can issue the command and it will reprogram, it will
set upper and lower sensing limits for the device on, you know, when to start shocking,
you know, when to stop, when to sense, you know, when there's a cardiac event. And so those
things you can also Man in the Middle. I think Kevin Fu, if you are really interested in the
details of that, he did a great job, you know, look it up. Take a look at his research all the
way back to 2008. There is obviously a clinical need for that, too, and I will bring that
up and that's one of the challenges that you get into this space is you know you would
hate for a patient to show up and, oh, I forgot the passcode in order to, you know, deliver a
shot. I have to reprogram this device. So that's the flip side of it. It's definitely, you
know, a challenging area. Externals? I'm not gonna talk too much about those, we have a
very detailed case example of a specific manufacturer on external cardiac defib that
we're gonna release today. >> It's awesome! (Laughter) >> And infusion pumps. These are
ones that they have web interfaces on them, oftentimes, you know, no authentication or
weak credentials, they also have accessible services. Medical device integration, this is an
interesting one. So historically, you know, some of the very critical, life-saving
medical devices that were out there. So ventilators, anesthesia carts, things like
that, they historically and for a reason, weren't ever networked, right? So they just
did serial interfaces and things like that; they weren't put on a network. Well, Affordable Care
Act and things like that, and having to pump all this data to a centralized location in order
to do BigData analytics on healthcare populations we have decided that we needed to
integrate life support equipment so we have gone with medical device integration vendors, a
lot of healthcare organizations are doing this now and it's bringing in these critical
devices onto the network, reading those vital signs and then ultimately transferring
off. Again completely unencrypted. No encryption. You can Man in the Middle that. You
can actually replay it. They do use unique identifiers but you can correlate it all the way
through from the unique identifier back to the patient. Whoops. >> So these are pretty
much the top risks that we've identified so far. Just across these systems and again there's
nothing terribly sexy about this, right? We've seen this for years. A hard-coded privileged
accounts. It never goes away. It's gonna be here forever. Unencrypted web apps and then
all kinds of API calls and then back-end services like Scott mentioned earlier with the Pacs
systems going to the storage interfaces. And then, you know, many of these systems are built
off of COTS equipment, so they're just using medical device manufacturers, they're
using your standard, maybe an embedded Windows or VX works or a Windows 2003 or 2008 server--
>> XP or 2000. We'll kind of touch on that as we go through examples too. (Speaking
off-mic). >> Yeah, or embedded. All over, yeah. Right. So they're not OS experts and
typically they are not removing the excessive services that are on these operating systems and
then there's the patching. So we'll talk about the patching issues more but there's a real
misconception out there about there about hey you can't patch medical devices and that is just
is not true. The FDA, there's no F.B.I. here, right, they weren't invited so-- (Laughter)
-- The FDA has issued guidance for the past ten years indicating that yes, you can
patch medical devices. But we'll get into that later about, you know, how you do that or should
you do that or what are the risks associated with that. >> Yeah so that's kind of the, you
know, first round of research, kind of dabbled into for the last few years. And we were
going to kinda stop there. But there was a lot of outreach to that and a lot of refutal of,
you know, points that yes, you know, you found these issues in medical devices but they are in
internal networks, they're fire-walled off from everything else. Well, you know I called BS
on that. It's definitely not how it is. And so I think we wanted to show that, you know, the
public was really unaware, I think, and even a lot of IS staff, inside of healthcare
organizations, were really unaware of this risk, and they truly believed that all their
devices were fire-walled off, that you couldn't access them directly from the Internet.
This is a blurb from a private industry notice, note that I'm not throwing off a private
industry notice, this was off Google and the media got a hold of it so don't think I'm
throwing out one of the F.B.I.'s hints to you guys but this is a, you know, a good quote that kind
of shows the biggest vulnerability was the perception of IT professionals healthcare
beliefs that their current perimeter defense and compliance strategy are working when
clearly the data states otherwise. So that is kind of, I mean, that's on an F.B.I. pin,
so they probably should start listening, it's just not some, you know, guy named Scott up
there telling you. >> And respect to the F.B.I. for doing that. I mean, for stepping up,
because if you really, you know, cut to the chase, this is almost kind of out of their purview
until it gets into a criminal matter, you know, I'm not a lawyer but, you know, this is
getting into the FDA and you know, HHS and so who has oversight of these issues? So
it's great to see that the F.B.I. is talking about this and raising awareness. >> Yeah and
physicians as well. I think there needs to be more awareness on that end across healthcare
organizations, a lot of systems get brought in from the physicians for clinical care.
Security is an afterthought of that decision that's been made and so we'll talk again a little
further on, you know, some involvement I have had now with, you know, physicians in
collaboration which is great and we need to, you know, bring that awareness up, all the physicians
I talk to, they care, they just don't know. >> I think really that's where we're gonna see the
rubber meet the road as far as physicians, you know. They are the ones handling and taking
care of patients directly. They are tremendously respected not only in the community but within
the organizations and they have a lot of power. There were MD students who were giving talks
at this conference, we are developing relationships with them, we are seeing in academic
medical centers an entire new generation of tech-savvy physicians getting trained so we
need to bring these people into the fold and explain the risks to them and then get them on our
side. >> You take this one, Shawn. You're following this awesome quote. 22:21>> So
everyone knows who Avi Rubin is, right? I mean he's a well-respected researcher,
Independent Security Evaluators , I think he's the president there, he's definitely one of
the founders. And I just thought this was a wonderful quote. And, you know, I have never seen an
industry with more gaping holes, if our financial industry, with regard to security the way
healthcare does, I would stuff my cash in a mattress under my bed. >> Yeah, so that says a
whole lot, I think. >> And that was in 2012, right, yeah, 12/25. >> Yeah, that was a couple
years ago. All right. So let's get into, like, first round of some of the exposure when we
started to look at Internet-facing devices, direct from Internet public IP. So we
started to research that, right, and we were doing some, you know, custom really elite
searches, like, for key words like anesthesia that no one would ever think of --
(Laughter) -- and we happened to right away within 30 minutes, we came across something that I
clearly knew wasn't an anesthesia work station itself. But we realized very quickly
that it had SMV open and I know who cares about SMV? I didn't come to hear DEF CON talk about
SMV just being open but I think the threat modeling that we're gonna show you is really where
that risk is and the information that we could extract related to medical devices and supporting
systems inside of the healthcare organization. >> So this was Scott's finding and we have been
exchanging phone calls while we're doing these searches and I'm sure those are archived
somewhere and perhaps someday we'll listen to them but yeah it was amazing, it was amazing to
see this. Because he was like, dude, send me this search -- he's like, did that finish
downloading yet of off SHODAN? I'm like, no, no, that still hasn't finished downloading, so
this is the results page of what, you know, the system is showing us. Like, no, no, so I
had to jump on a VPS server that has like a 10 gig or 10 meg pipeline and you know, pull it
down and got a quick page count and it was like, you know, 1482 pages. >> Just that one of the
thousands of organizations that you talk about here. >> Yeah, but this was one box off of one
organization with one port open. So it just shows, goes to show that wow, just one exposure. >>
So here is a little bit more information on the initial healthcare organization
discovery. This was the first one we found. I found it probably like 10:30 at night and
was calling DHS at like midnight saying, hey, you know, we got an issue here, took the day off the
next day and worked all day to find out, you know, was it just an issue with one organization
or was it really, you know, a systemic issue across healthcare, you know, and the
hundreds and thousands of healthcare organizations were wide open externally? Well,
turned out to be even though we're using one example, the first example that we found, you
know, it's not just one organization's issue. It is across the world in many
instances and we will show you the statistics that we have on that. But to give you an idea
of size it was a very large U.S. healthcare system. They had over 12,000 employees, 3,000
physicians and you'll see when we get into the actual medical devices and the systems that
communicate with these medical devices, they did have a large cardiovascular neuroscience
institutions attached to those. It exposed intelligence. When we dump that 1500-page document
after we finally got it downloaded and extracted all the raw data, it was over 68,000
systems provided a direct attack vector from externally anywhere in the world, public IP, into
those systems. Full control if an attacker wanted it. It also exposed one of the things that
we found that, again, isn't, you know, unique to this organization. It's across the
thing, is we've seen indicators of, you know, third party organizations that were
connected and contracted for certain services so, you know, specialty services, things like
that, that are contracted out by other organizations. We have seen those systems and, you
know, names used that were affiliated with those systems inside of there. So it wasn't
just these organizations had an issue; they were also exposing third party connections and
security issues there as well. >> And ene thing, too, this also exposed a lot of your
internal business operations so HR systems, payroll, what we traditionally think of, of an
attack vector and what attackers were going for. Interestingly, we were looking for healthcare
and medical exposure here so there was PHRs and all that but it was, yeah, it was
disconcerting to see all that business process systems exposure as well. >> Yeah, so I
think that's a good point. 'Cause it definitely wasn't, you know, our focus was on, you
know, medical devices, healthcare infrastructure, things on patient safety but
this was, you know, these 68,000 systems weren't just medical devices. It was their entire
infrastructure and so we can give you an example on all those medical devices and supporting
systems that we found but we also, if we were into talking about that could've shown you
just as many examples with financial systems, payroll systems, you know, employee-type
confidential information as well. >> So again, you know, did we find only one? No, you
know, we found hundreds. When you link them together, when you change the search term, so you
can see right here this is a screenshot inside of SHODAN, but what we're doing is, so you can
see the hits, so we are just doing searches and then we're using key words that would be
associated with medical facilities. So health stocks, any type of like healthcare
system that has that in their organization name. Clinic, hospital and medical and you can
see the number of hits that have this exposure. Well when you change that into, you know,
specialty things, like if you change that search term to like cardiology, or radiology, or
urology, or pediatrics or something like that, you're gonna get all the organizations
that have that inside their org name, and then when you tie those into the third parties
that were affected inside of those disclosures you end up with, you know, thousands of
healthcare systems that are really affected. >> So what's key to think about is, you know,
there is a lot of specialty small clinics so when we have gone out and maybe got an MRI,
you've got sent to a special, small specialty clinic, and these are all, you know, tied in
with the healthcare systems, too, and you know, the kinds of searches we did here, with just
the org name, if you are looking for, you know, specific clinics you can do those types of
searches too, and really get granular, even by geographic areas. So SHODAN is a very very
powerful tool, it's not the only tool to use this but it was, it was, it fit our needs and what
we wanted to show at the time. >> And so here's some heat maps. And if you haven't checked
out SHODAN lately we had access to the beta thanks to John, and we actually have been able to
work with him to do custom searches for certain ports that aren't publicly available just
to dig into a little bit more specific medical device exposure across the Internet but these
are some new heat maps that he came out with so definitely go in and, you know, check this
out. It's kind of a neat feature. It will not only show you the heat map overlay but it
will also show you top affected domain names, organizations across the world. So this is
just some heat maps for key words of what we did and kind of the concentrations for high host
down to low host count. You will see kind of a theme here that it is U.S.centric, I don't know how
to spell health insurance in Chinese if they put that in their org name or things like
that so I don't know if that has to do with some of the disparate information or not but the U.S.
definitely is a big red dot on all this stuff, so. This is one for the clinic, as you can see.
U.S. is still definitely top on the list for organizations that have this issue. Same with
hospital. And here is the heat map for medical. It starts getting a little more
interesting, China and stuff starts getting big and red. One thing we did do is we don't
cover it in the talk but I'll just talk about it, you know, quickly is some of this
customized stuff that we're doing with SHODAN, and that was just released as well, is X 11,
so if you want to go and search like Port 6,000 X 11, we did that with John and he just
released it publicly. So there's a lot of unauthenticated X 11 devices. We weren't able to
correlate it back to medical devices so we are not talking about it but he has released it.
There's like 60,000 systems out there, 30,000 of which are completely unauthenticated
across the Internet. So who cares about SMV again? You know, why did we skip Dan Kaminsky's
talk to come watch a bunch of posers talk about SMV, right? But that's not it. It's really
the threat model here. And why does this matter? You know, who cares? Well, this system and
others like it also happen to be Windows XP. And it's vulnerable to MS08-067 and for those of you
that weren't in the security industry back then, that is you know the exploit or the
vulnerability that can configure utilized. So this is old. This is from 2008. Still have
external-facing systems running SMV. Also you can pop that box direct. So this is kind of a
host profile, the OS, just a screen cap, obviously the information is hidden on this
organization. >> And I pushed back against Scott on this, too, when he first brought it to me.
I was like this really isn't that interesting. Once we started looking more into the
full exposure of this organization and he painted the picture for me then it became
much clearer, and so that's what is -- >> Yup, I think that's what is coming here. So why does
it matter and what, I'm gonna show you here in the next slide why does it matter. Well the SMV
as we know, it by design is gonna leak host names. Well who really cares about host names
necessarily? But what we also realized with these healthcare organizations is that not only
was SMV open but read access, anonymous read access to their Active Directory infrastructure
was also pulling through directly to the internet and exposing all this detailed
information that allowed us to identify, you know, specific medical devices, not just
medical devices themselves, but the supporting technology systems and applications. And I
want to, I want to clarify on that. Everyone talks to medical devices and a lot of people may
think that it's just, you know, implantables or just the actual device itself. You know, the CT
scan or the MRI system. The actual infusion pump. But understand it's a large
ecosystem here. No longer is it just stand-alone systems. So those work stations that they
are using, they interact and they have the application that issues instructions to the
medical device, to the patient. So that's why, you know, all these work stations and things
like that are so important. 'Cause they do have direct access to communicate with the
medical devices through the application. So leaked out host names. And it oftentimes leaked
out very specific information that attacker could use. So we'll show you some examples in
here of, you know, the floor, the office, physician names are in here. And also AD policy was
applied so like the ORs, by design most healthcare organizations set timeouts on
ORs. >> Who are they? >> Yeah. And, you know, the reason they do that is 'cause they're all
scrubbed up, right. I mean that's the, you know, the reason they don't want to be messing
around with big clunky gloves having to unlock it. You'll see some examples here that shows us
that the specific systems also have timeout exemptions in place. So let's get into, you
know, what other systems we found, show some examples here. Why does this matter. Let's
paint a picture of why, you know, it's not just SMV but it's really a threat model here. So
over on the left you can see those are the systems with the lockout exemptions, so that is
something where we know that the screensaver time out isn't gonna kick in so that matters, right,
so especially in like a physical attack scenario that we get into later, that matters because you
want to know what system has a timeout exemption. Over on the right, here's this customer
happened to use Epic, please note again this isn't a manufacturer issue. This is just
the organization and all these organizations had a misconfiguration. So this isn't
anything that Epic or a manufacturer can fix themselves but this is just an example. You
can see all their servers here, these are used for everything from the SQL server back end all
the way into web servers, I believe down there towards the bottom, MyChart, MyChart is if
anyone here goes as a patient to a healthcare organization and they use Epic, MyChart is your
portal into all of your medical record data. So that's this organization's server. We now
know we can hit it directly from the net. All right. Let's talk about a little bit more stuff.
So pacs imaging. We talked about those previously. We have seen through our research that they
don't require on the back end authentication or the one manufacturer I have ran across
that does, the little kids over in Roots could probably crack in about three minutes, so it's not
very difficult. So here is radiology systems. Here is the CT system. Pacs, you know, CT3
right there. So that's some of the radiology stuff. Down at the bottom, telemetry. There's a
couple use cases for telemetry systems. We can't tell exactly just off this what exactly that
device is for. We can only profile on this case. So telemetry can be used for
different things. It can be used for infant induction systems or wandering adult patients, those
types of things. They use a little armband to alert, you know, if the mother, if the
child are too far apart or if one gets taken off the unit. Telemetry is also obviously used
and we'll show you some examples of this, for pacemakers, pacemaker controller type
systems. Speaking of pacemakers, here are some pacemakers and we also had specific examples that
were very labeled as pacemaker controller. So we know that those were the pacemaker
controller systems inside of an organization. We know that those pacemaker controller systems
don't require any type of authentication to communicate once they have associated to a
implantable. You can also see here, we have scrubbed it but there's an example in here, of
you can see doctor or whatever that is and you can see those types of examples. Specifically
where they are at. Second one there, there is pediatrics. Nuclear medicine. Down at the
bottom, this is when you get into anesthesia, right. Anesthesia OR, we know that this
is an anesthesia work station. The OR environment is very controlled so thinking that you
would have anesthesia OR labeled separate from the anesthesia work station that is directly
attached to the anesthesia cart, there is just no way, this is definitely an anesthesia work
station that is on the anaesthesia cart inside of the OR. You could hit it directly
from the internet. So we found a few of these devices, right, you're giving us some examples,
you're showing us some screenshots, types of devices that you found. Well, we
didn't. We took that big log for this specific organization of the thousands that we found, we
dumped out the raw data and we started to extract that data and we identified thousands of, you
know, the medical devices and those supporting systems and those applications. So we used
our favorite data extraction tool called Excel 'cause we're really sophisticated. >> He
did. I haven't gotten my Excel certification yet! (Laughter) >> Yeah. So this is a overview.
So we took all that raw data, we dumped it to Excel and then basically what we did is we just
did a search and a find for key words on these types of devices. So we did a search for
anesthesia. There was 21 systems that were affiliated with anesthesia outside, inside this
organization. Cardiology, 488. Like I said before, they had a very large cardiology
institution and a nuclear medicine, nuke med, neurology institution as well. Infusion
systems, found 133 systems. MRIs, 97. The Pacs systems, 323. So I think right here again it
goes to the point that I don't know, maybe healthcare security is lax enough and poor enough
right now that the attackers, you know, are not using this simple attack method to get in
and get information on the devices, maybe they are just plastering everybody and they
are able to go completely undetected. But if not they could do a little bit of
research and they could find out, hey, just this one healthcare organization has 323
you know, devices associated to Pacs and imaging in some way or another. Nuke med systems, 67,
and ultimately on the cardiology side 31 systems associated to pacemakers. So potential
attacks in this scenario. Threat modeling for this SMV exposure that leaks all of this
information, right. We've got a few of those. The lamest one but still a viable option is, you
know, physical attack. We now know a lot of information, we know what types of systems they
are as a attacker. We know what types of medical device they are associated to. We know the
healthcare organization and the location, we know the floor and the office number in lots of
cases like I showed you and we know if that system has a lockout exemption. So we can now
very strategically, right, Shawn, we can walk in and kind of pinpoint, we want to go to
this floor, this office number, we know it's a cardiology doc that's seeing this patient, we
want to go walk in, we know it's got a timeout exemption, we can probably sit down and never have
to put in a password and get access to that system. >> And when it comes to healthcare
organizations, you know, it's not like walking into a finance institution, financial
institution where they're like a beady-eyed banker looking at you like you're gonna take his
money. Healthcare organizations, you walk in there and there's people at the desk, hi, how can
I help you, right? So they are very susceptible to a number of physical types of attacks. Plus
you throw a lab coat on, put a stethoscope around your neck, you print up a badge, which you
know, you can just easily do just from trolling the halls and looking to see what they look
like, you know, it really opens up a scary avenue of attack because nobody really thinks
about this. >> So what's the next one that we can kind of look at for an attack in this
scenario on these organizations? Obviously a phishing attack, we're all very familiar with
that, right? Agn, we know what systems they are we want to target. We know the healthcare
organization, we know employee names, and so we can just start extracting email addresses for
those employees. You know, that's very simple to do. And we know the host name and that's
the key thing. We know the host name and we know what type of device it is. So we can write
customized payload now that we can deliver through a phishing attack that once it's executed
and once we have control on that internal system or even from that external-facing system that
had MS08-067, we can directly pivot to only hit the devices that we want to hit. So an
attacker can be very strategic with this type of information, right. They don't have to, you
know, get a foothold and then scan the entire network and figure this out and be really
noisy. They don't have to do that. They can simply send a phishing attack and then target
directly toward those medical devices. Pivot attack, this is obviously external for those
systems that had vulnerabilities. MS08-067 is just one of them. A lot of them
are running vulnerable versions. IIS 6 that are sitting out there plus a lot of extra excessive
services that are vulnerable as well. We also know in this pivot attack that's touching the
back end network because it's leaking all the data for everyone of their things. It's
also giving us read access in the active directory. So we know there is a hole and that there's
a hop and that it's not firewalled off. So again we can create a custom payload directly
and pivot internally. Targeted attack, this one is, you know, where you start to make the case
for a targeted attack against a targeted patient, those types of scenarios, right. We can use the
information we got over SMV so we know the systems that are associated. We also now know
every single name of every one of their medical record servers, so all we have to do is
strategically target those specific systems once we have a foothold in the network. So then
an attacker can take that, attack the medical record, get a weak password, get a
vulnerability and some legacy application and we can start correlating where the patients
are gonna be when, and correlate that with the SMV data of where these devices are located and
what type of devices they are, and then, you know, launch an attack. So, what's the good
news out of this? I just want to touch on this example of healthcare organization. This
was very positive. This is new space DHS and ICS-CERT did coordinate disclosure and with
this healthcare organization among others that we used in our example, they did schedule a
follow-up call. And so I did talk with healthcare organization and DHS. They
actually, it was a very positive exchange. So typically we are dealing as security researchers,
we are oftentimes dealing with manufacturers, right, and we're starting to get over those
bounds as well, but initially, and the first time with everything, you know, there's a
lot of legal land mines and pit falls that you gotta get through. So this was a big win
for us, this is something that, you know, I'm proud of. This is the first time, you know, DHS
says they've actually worked with a security researcher and an actual healthcare
organization to expose these risks and work through it. They did -- (Inaudible) -- they
showed good faith. I'm not gonna speak to what it contains but they did actually share their
full incident response with me and I went through that with that organization so it was a
very positive win overall in that interaction so I want to call that out. So next Shawn's
going to talk on public Internet facing systems and is there any device that directly is on the
net? >>I should have stayed over there. I liked it much better. So that was the first
part. Kind of our talk here of the SMV exposure and just bear in mind we focused on one
organization but we could have done this with a number of organizations. But just for the
brevity and the exposure we just did that one. So medical devices on public Internet. I mean you
really wouldn't think this is the case, you know. So a public IP address and then you have
this medical device here, but it is and some of these are by design and on purpose. And what
really makes this tricky is that some are using cellular modems so, and the reason is they may
be remote clinics or they want to separate that in some ways from the other infrastructure,
but what that does for, you know, ethical researchers who want to track down these devices
and then ssociate that with the healthcare organization, it makes this very difficult for us
to do that. So that's really where we need to reach out, you know, to the carriers and the
FDA and HHS and even law enforcement because they have the capability to correlate
those cellular modem addresses and IPs to these medical devices. So this is just four
examples that we focused on of what we found out there. And I mean hese are publicly
accessible on public IP, defibrillators and those, Scott's gonna really give you an
excellent case study about that later on. They're deployed in ambulances and then these fetal
infant monitoring systems which, if you follow any of my SHODAN talks over the past few years
I've been yammering about, I'll get into more of those. EEG systems, so those are hooked up
to folks at home and then they're tied into a cellular modem. And then of course Pacs
and imaging systems, now the really the interesting thing about Pacs systems is when they
take these MRI images of you, they are gigantic files so there's a storage back end, we
talked about that, but then transferring them is an issue too. And then what's going on is
there's consolidation in the industry of analysts who are specialized in doing this type
of analysis. So there may be someone working across the country from home and doing all
day long, you know, she's just looking at these images and then doing the analysis, writing up
the report and sending that back to the healthcare organization. So it makes it much easier,
right, to just stick this out on public IP. They can access it directly over a web interface.
You don't have to allocate a VPN session to them. They are not choking up your bandwidth and
that kind of thing. More traditional hardware infrastructure that we found
exposed was just your old unauthenticated and misconfigured Cisco devices and
edge routers and these have been known for years. They are really easy to find. And then also like
device manufacturer infrastructure and then, you know, these third party contract
organizations. What I mean by that and Scott's gonna talk a little bit about this, too, if
you want. But what I mean about that is, hospitals are tremendously complex
organizations. So, you know, just because there's a device on a hospital or a healthcare
network doesn't necessarily mean they even own it. They may not even know about it. And when you
get into like academic medical research centers you may have a professor who is also a
physician, so and then they have somebody they are doing a research project on and then
they got this device and then they allocate it to a public IP. So, you know, the IT folks may
not know about it. The security folks typically will not know about it at all. And so these
things just show up on the network. You have something to say on this? >> Yeah, I think
in the healthcare systems too, understand, the one that we found, the one that we disclosed
to DHS, this wasn't a small family clinic, this was a very large healthcare organization.
It was not the same organization as the other example but it was very large, they had over 13,000
employees just to give you some idea of size of the organization. So it wasn't a
small thing. Completely on/off edge router just sitting out on the net, all their
infrastructure was exposed. A lot of the manufacturer's side, what we've seen and is
accessible, a lot of those that we found aren't necessarily you know the fault of the
manufacturer; it's really implementation issues at the location but some of those come
back to poor documentation or guidelines from the manufacturer. We see some
documentation out there that is straight up for support reasons. In their documentation it tells
you open every single port on the firewall for remote connectivity from these vendors
which obviously is a little reckless. Not sure how they are QA'g those documents, it's
obviously not needed and some folks are doing it. >> So we got a few case studies that
we're gonna walk through. And this was the first reported medical device, meaning reported
to ICS-CERT. And I found this in late 2012 and it was a Roche glucose meter. So this is a
portable glucose meter to take blood sugar measurements and it has this base station on there.
And the base station just had Telnet running but there was authentication required for it
but Telnet, I mean it's clear textbook protocol. The vendor response was awesome, hat tip to
the Roche guys, they were all over this, good communication, and then really good DHS and ICS
response on this, too. This really gets more troubling. And I alluded to the Pacs systems
before and the reason why these are exposed online and there are hundreds, and even if you start
doing different versions, really thousands of them, and this is just the Kodak ones. And so,
you know, Scott talked about the ecosystem before, right. So it's easy just to think, oh the
stand-alone medical device, and what are the risks associated with it? But there's a whole
client infrastructure that comes along with this and how do your clients communicate with it?
And if you see here it's required to use Internet Explorer 6.0. On this system.
>> Yeah, that's not that uncommon either by the way! >> So it's not that uncommon but
then you think about these systems and okay are they dedicating that box, you know,
and that client browser just for that system? Or is whomever is using this gonna jump online and
start looking at different sites and get hit with a drive-by browser attack or something bad
through their Yahoo! e-mail. So again, it's just perspective but again, and these are on public
IP. This fetal monitor, I've been yakking about these for a couple years now. And so I first
reported these in about December of 2012 and then there's also been some media coverage. So
these have been mentioned specifically in mainstream media and I haven't really had people
reach out to me yet about these which I was surprised because I mean if there's one thing we can
think about is fetal monitors, my perspective is that you should have the opportunity to
be born before you get hacked, right! (Laughter) That's not too much to ask for. Okay. And
these are the most severe, these are the most vulnerable people in our population. I mean you
got a mom in bed expecting a baby. Can't we do better than what we're doing here with this?
So when Scott and I decided to collude and do this talk I really amped up. And I
disclosured again to DHS, and then went to the manufacturer whom I'm not gonna mention the
manufacturer, and I'm not gonna mention the device specifics on this but I also went to the FDA,
the Office of Civil Rights and the Joint Commission because I'd gotten to the point that, you
know, if you put these out there, you put people at risk, you deserve a fine. And that's
the business side. Right. That's when people start paying attention. (Applause) Got to
hit'em in the pocket. So here is a SHODAN map of the fetal monitors on public IP and it
really doesn't disclose-- >> That's a really crappy picture! >> It's a horrible picture but,
you know, if you look in the United States, right, you'll see one big dot. And one big dot in
the United States is there in the center, you'll see a couple down in Florida and down in
Puerto Rico but the ones in the U.S. you see a big dot there, and that's because of the
cellular modem issue, right. And so it doesn't give you a geo-- SHODAN will not give you a
ge0graphic location on that cellular modem. So we got a fetal monitor hooked up to a
cellular modem, don't know the organization it's affiliated with, very very difficult to
track that down. Anyone, and that gets into a phone call I had with the FDA. You know, the
first question to the security guy was like, oh, well, how do I find these? I'm like, dude, call
the F.B.I. >> Yeah it ends up being just so you guys are kind of doing your research, and are
aware of that, it ends up in a field like 10 miles northeast of Potwin, Kansas, and so that
field is actually a geographical center of the United States. And so anything that is not able to
track a geolocation back to, that is why you'll see a huge influx outside of Potwin, Kansas
in a field. It's not a bunch of people out there with fetal monitors and devices sitting.
(Laughter) It's not a hacker camp in the middle of the field. >> Kansas is so boring, you
almost want to drive around it! So here is some system details on this. Now, so there's two
different models out there running. First is Windows 2003 server running it's running
IIS6.0 right, 16 systems. So doing my research on available public documentation, you know,
and that's another thing, documentation control for this on the vendor side, they get
third party integrators, these guys pop up an FTP server and then the vendor documentation
gets leaked out so then a guy like me can come along and then find it. Usually it's very
tightly controlled so I knew right away after documentation that these 16 systems that are
out there are behind on their vendor updates. And props to the vendor because on this
particular system they are doing a good job, they're actually vetting the patches, they're
upgrading systems and going up CDs but then you get in the situation where these are
constantly in use and you have to have an IT department, upgrading them or you have to
contract that out. You get smaller healthcare clinics, money is an issue. Think about
how it is on like a Native American reservation, right, you know, these things are expensive
to run. The second one was the 2008 server and that's IIS7.0, by the way not all these systems
are currently exposed online so there's a historical context here but over the past couple
years I've just seen more and more of them pop up online. So some have been retired, some
have been taken down. So the remote access is done through remote desktop web access, which
is done through a browser or there's a terminal services client. And when I did raise the
question and did get in touch with FDA and vendor I couched this 'cause I knew I could get
their attention, couched it as a HIPAA-compliant issue, not just a public IP exposure but the way
the communication happened with the RDP clients. And there is technically ways, I'm not a
HIPAA expert, but ways to make it HIPAA compliant, and using the FIPS, correct FIPS, approved
crypto levels, certificate sharing and such but that really wasn't documented. From what I
saw and from other documentation, what could have been and, yes, so there were
some questions about that. And then again I'll give props to the vendor, because they said
that these should be deployed on a secured connection, so meaning, you know, with a VPN
and I believe that they will be updating their documentation. >> Yeah so that's one of the
reasons we are not naming the vendor. We don't feel that this one is necessarily a
manufacturer issue. If it was a manufacturer issue and they were actually recommending that we
expose them, we probably would drop their name as I will drop a vendor name later in this
discussion. >> Yeah stay tuned. It's gonna get a little hairy. That's all him. >> The FDA
Module reports, so if you're not familiar with the FDA, there is a user event database that they
have, and so what I did is correlated, I didn't do correlation. I went into FDA Mod
and I was looking for anything that could be tied to this particular monitoring system,
what kind of problems they've had from the field that people have reported. So some of those
I saw that these alarm capabilities have been muted or disabled. And that led me to
wonder, okay is this possible that, you know, these particular exposed devices, is there
correlation with the FDA Mod database in those reports that perhaps there's an attack going
on here that we don't know about. It's hard to tell from Mod and Mod reports are really,
they're sanitized search interfaces are horrible. So, where we are today, is this is
close to DHS. There's many on public IP, many are running IIS 6.0. And by the way I'm able to
tell all this from SHODAN so I am not going to these individual systems, I'm not connecting to
them, I'm not looking at the versions, I'm not scanning them. I can derive all this
information from SHODAN including last scan date so there's a historical record in
SHODAN. The vendor did reach out to me. We had a conference call. They are interested in what they
characterize as a customer misuse case. And that is completely accurate and really
it's the beginning of security researcher communication. You know, one of their security
people was like, yeah, I've known about you for a few years, you have the med sector group,
you know, we get a little apprehensive talking to you. And the reason is 'cause they don't
have have you locked in right, I'm not a under an NDA, I'm not an employee, I'm just a guy out
here who is, you know, interested in this, and wants to improve public safety. So, you
know, it's a wildcard, right. How do you handle somebody like that? And I can appreciate that,
so. I believe that they might have sent a folk or two here and I hope we can rap up here later,
you know, continue to build has relationship because this is where it's gonna count. >>
Lessons learned: really, you know, we need a better reporting method. We need to have some
teeth in something and a way to track these formal government levels, we need some
coordination happening across these different agencies. I'd love to see like a task force
that evolved out of this where okay we found a device, we're able to get the public IP
correlated to a healthcare provider, send the people in, ask them to disable it. If
there's a PHI leak or something along those lines consider a fine. Again, I'd hate to see a
small poor hospital out in the middle of nowhere get hammered with a HIPAA fine but again it
makes the news and hopefully that drives change. >> So let's talk about some adversary
misconceptions and some e-mails that I've gotten on our research, public comments,
people that I've had to deal with. One of the things that I get is: Well, who the heck would
do this? They only care about financial gain, right. They don't care about anything else.
All they care about is going into those Pacs systems, actually draining patient data,
and selling it. And yeah that's true, Russians, they're gonna sell it right, that's what they
do. But the other thing, the other misconception, and honestly there was this guy that
posted on a recent article and he actually said ignorant people, he said that, hey, these
people lives in caves and you're giving them all the information to get into the devices. And
they're not smart enough to figure this out on their own 'cause they live in caves. I had
e-mail communications with this guy like 30 times and he just wouldn't give it up. He was so
convinced that they aren't technically adept enough to carry this out. And as we showed
you, this is not a technical attack here. This is basic Security 101 concepts that one
thing gets missed and there is kind of this cascading effect for patient safety right, and it
opens up this huge threat model that we have to be aware of. >> So who do we need to worry
about? I think, you know, terrorists and extremists, technically adept, when you get
into, you know, ISIS, when you get into nation states, that's kind of who we need to worry
about and that's what I thought about. And then Shawn, and he can talk to this, he brought up
this interesting article that I'd never thought of, oh man, a patient, maybe themselves could
be an adversary in a way. So I'll let you talk about this article. >> I'll quickly run
through this. So here is the situation, you know. You've got a patient in a hospital with a
gunshot wound, guy's lying in bed, he's got his laptop there, and he's got-. >> This is
awesome by the way. >>And he's getting a morphine drip right through an infusion pump. So
obviously he's like I'm in pain, I want more juice. How do I do this? The guy went online.
(Laughter) >> We didn't make this up. There is the link. >> Guy went online, found the
manual for this infusion pump and then was able to break into it and then reprogram it and he
ended up going into an overdose and then it happened to a couple guys in this healthcare
organization in Australia. I'm sorry, Austria, and, yeah, so you know it's just something
when you think about, it's like, oh, we always think about, you know, who is at risk and who is
the adversary here. Well, you know, the guy who's being treated for this could very well
be the adversary from a healthcare standpoint. >> So one of the things that really,
you know, gets scary and this is easy to kinda dismiss as a, just theoretical or you're watching
too much TV or reading too many books, but think about these Boston marathon bombings and the
Tsarnaev brothers, right, and think about if they had set off ten bombs and then, you know,
timed another ten to go off, right, when all the emergency personnel came in. This is what
happens in countries like Israel, when we see the first bomb goes off, all the emergency
personnel rush in there, then the second one goes off. And what I think we're going to need
to start worrying about in the future is gonna be the electronic attacks against the
critical infrastructure like hospitals and power but more so hospitals because they're such
soft targets. Think about the impact of a, you know, a bomb goes off, all the EMT guys get
hit with the second bomb, then they're bringing everybody to the hospital, and then
everything shuts down in the hospital. Even Boston Children's recently got hit on their public
website because of the Peletier case which Anonymous picked up on so we are seeing this already
starting to manifest itself. And it's all about capability, right. The capability is there
to do this. >> I think one thing to add, too, I think this is where, you know, historically
DHS and ICS-CERT are the ones issuing advisories, it wasn't until April that the F.B.I. all
of a sudden got involved and they issued two privacy industry notices last April. They kind of
came out of left field, like why the hell is the F.B.I. all of a sudden issuing private industry
notices about risks in medical device exposure? This is one of their fears, right, is the
combined attack and that's the type of thing that they are looking at, that's why they are
looking into the space a little bit more closely and why they've, you know, we started to
work with them and build that relationship up is really these types of scenarios. >> Right,
so the military term for this is force multiply. >> So Ed on the bottom here, Cybercity, they are
already doing this, right. You know, the government obviously is looking at it and they think
it's a risk, we should probably take a look at it, I mean Ed has been doing this for a few years
now but Cybercity has basically, they have all that critical infrastructure. They have
detailed all that critical infrastructure, so they have the healthcare, they have financial,
they have the ICS stuff, they have transportation, it's just a big, you know, training lab for
if a combined attack took place, how would we be able to react for it? So it is taking place
already. >> So really, one of the questions that comes into this is, this is a whole new
area of medical devices. How do you even know that a, if a medical device was hacked? You
know, one of the first things that you'll read about when you start looking in this space in
the articles is to say there's no documented evidence of a medical device attack happening.
But how would you know? I mean we don't have the forensics capability really mature yet at
all in this except for there some is open source stuff, right, that's built on cots
equipment. But it's mostly closed-source code. Vendors aren't sharing this code. And
then with these devices you need specialized diagnostic equipment, you're running
proprietary protocols and code so it's very very difficult and you need specialized people and
a vendor to help you with any type of cyberforensics exercise. Then you get into the device
experts so, you know, looking on LinkedIn I only found two people who really claimed any
expertise. >> Definitely an official source, way better than Wikipedia! (Laughter) >> Yeah
but only two people that I found. And the first was you know, a woman from the FDA,
total track record. >> Not an expert. >> Then the second was a retired F.B.I. agent, who was
one of the founding members of their cybersquads, so those are like two people, but. So those
of you who are thinking about forensics in the future and maybe if you are in healthcare,
this is something that is to consider as far as a career path. >> And one thing here on
this last bullet point that is important to understand, too, when we talk about, you know, a
low assurance that an attack, either intentional or unintentional, hasn't taken
place against these devices with adverse events. The FDA adjudication process of a
medical device related malfunction that gets reported. Healthcare organization has the
responsibility in requirement to report a medical device related malfunction, and so they report
that to the FDA. Well if you go to the FDA's website it will directly tell you and their
quotes are several hundred thousand of medical device-related malfunctions. So
they adjudicate this. If something happens and there is an adverse event for a patient
they do a clinical adjudication to say, oh, the patient died from pneumonia on a ventilator
or there's, you know, they died of old age or that type of thing. If not they don't really
do, you know, security. They don't look at forensics because there's not a whole lot of
information there to look at. And so they throw it in this generic button, or bucket of
several hundred thousand medical device-related adverse, you know, deaths and serious
injuries every year. We don't know what they are. And then the Mod reports suck and they're
very specific and script out. So we don't really have the information and we don't have
the forensic details so, you know, how could we really prove this at this point? >> So let's
get us into HIPAA. I'm gonna flip through this really quick. Oh, you're switching with me.
>> You know, yeah, HIPAA. I'm not gonna argue that it's ineffective, but why are we in
this space? Doesn't it protect us? I get this too. I get all these e-mails all day long, why
isn't HIPAA doing something, right? HIPAA focuses on patient privacy, it's not focused on
necessarily patient safety. Human life is much more irreplaceable than PHI. So I
would encourage you guys to start looking at that if you work for healthcare
organizations, definitely start looking into that. It doesn't focus on medical devices and it
definitely doesn't focus on adversarial resiliency testing at all. Don't the federal
agencies protect you? That's another one. Shouldn't the FDA be doing this, right? Well, it's
ultimately your responsibility as a manufacturer, as a healthcare organization, they
have told healthcare organizations, they've told manufacturers since last year
when Billy Rios, Terry McCorkle came out with the infamous 300 List and these are some of the
alerts if you want to look them up later, that came out specifically telling healthcare
organizations and medical device manufacturers that they at this point aren't gonna get involved,
and that it's their responsibility to take care of it. So how did healthcare kinda
get to the state that it's at, you know, ten years behind? It's back to HIPAA in my opinion. If
you work in the industry, information security programs in healthcare were primarily funded
and developed to comply with HIPAA. So we all know security is not compliance or information
assurance but that's how these programs have been built, they have been built for check box
security, and we buy this appliance and we check this box, and oh, hey, we are secure
'cause HIPAA says we are secure. Where are the issues in the manufacturers? Well we've never
had, you know, this is kind of the similar space, even in the auto industry, right.
Historically especially when you look at, you know, life cycles of these devices, that for
implantables, if they're not on expedited approval from the FDA from prototype to, you know,
market release, it could be 12 to 13 years. So we never have had to design for adversarial
threats and never really thought about it. We took these medical devices that existed and we just
decided oh it would be great if we could get data on this and managed them remotely so we
don't have to waste time, and be more efficient but now we kinda have the unintended consequences
that we are seeing here in our research across healthcare organizations. And the other
thing, you know, they haven't fully embraced, this is getting better, most of the large
healthcare manufacturers are starting to reach out, we're starting to build those
relationships, there is a lot of one-offs, you'll get to one of these examples, of a company
that just will not talk to us coming up here that we're gonna show a use case on. But so if
you reach out to us and actually talk to us we probably won't be as mean to ya! But no, you know,
we are really there, we have a combined effort and they are starting to embrace it. We are
doing a really good job, we're making a lot of progress there so I'm definitely hopeful, you
know, that that will continue. You know, it's not, when you talk to the manufacturer and you
know they don't care. You know, to their benefit, I mean they are very large, a lot of this
does take time, it is a culture change and so they are getting there. They are building out
these teams. They are hiring the right people and giving them internally the authority but
this is just some of the larger manufacturers, not these one-offs, not to mention when we
get into digital health and mobile health things. So does anyone work for healthcare
organizations that wants to admit it? Okay. All right. So how many of you have been told
by a manufacturer that you can't patch your system, like your medical devices, right? Exactly.
It's a crutch. And here is the link. I mean like Shawn said, they've been telling you, the
FDA, there is, you know, cybersecurity clause for patching. There is a very small
percentage that would actually have to go back through 510 k, the only case is if it's
clinical care issue, patient safety issue on some types of implantables. Who else has been
told they can't change hard-coded credentials that they may have located for the
manufacturer, right? All right. So that gets into my next bullet point. I want to, you know,
spend a little time kind of clarifying this. This is a big point. Both sides need to
understand this. So if you are in healthcare, you know, please listen to this. On the
healthcare side, whose biomedical teams are integrated with IS? Oh my God, there is not
a single hand that I can see. But I'm a little blinded. >> We have two over there. >>
Awesome! That is great. So how this works and where this disconnect is, is you as someone
in security, you find a bug or a flaw in a device that you want to report. You go to your Biomed
technician, your Biomed tech takes your report, interprets it in his little Biomed language
and who does he contact from the manufacturer? He contacts the support technician at the
manufacturer. Well the support technician is not their security people, doesn't have any idea,
so they get your report that says we have a hard coded credential, how it works on the
manufacturer's side is that field support tech goes to their supervisor and says, hey, we
have a report from a customer that we need to change this. And the supervisor is like, hey, how
the hell are we gonna get into the customer's systems if we change the password, right? So
it stops right there. And he's not thinking security, right. He's not their security person.
But he tells that field support tech to tell the Biomed person that they can't change it. And
so it comes back to the health organization in a way as the official response from that
healthcare organization is they're not gonna fix it and we don't push it anymore. So
there's a big disconnect there on both sides, there's a disconnect between Biomed and IS
on the healthcare side and there's a disconnect between how do we inbound handle, you know,
vulnerabilities at the manufacturer to make sure that the security folks at those
organizations that have implemented those programs can effectively be aware of them
first off, and then drive the process behind that to make sure they're resolved. And also I
would highly encourage you to, you know, know those information security people so if you don't
know especially at your big vendors, the ones you spend lots of money and have lots of
equipment with, reach out and find out who those folks are and build up those relationships.
'Cause it's very important. >> So when it comes to patching, you know, the question is: Yes,
you can patch. But should you? So there's a good eight, 10 years of FDA guidance saying
that you can patch these systems but this is something that you really need to work on your
vendors with and do coordination because you have got a very complex ecosystem going on here
and then what if something that you do in-house breaks the device? So, you know, the vendor
coordination has to happen with this issue and there's gonna be some smaller vendors who are not
going to be ready to work with you on this as well as a larger vendor would be. So the other
thing is many healthcare organizations are reluctant to patch just because of the
complexity and the changes that can happen in these systems. And if we go back into the FDA Mod
reports, there's many many examples of patches that have gone wrong or healthcare
organizations that are comfortable patching say the computer PC that connects to the
medical device that's running, both are running Windows, they'll patch one, the one you
used to run the device but they don't want to patch the device itself that actually connects to
the patient. Which is completely understandable. The anti-virus question is another one. And you
know, we can get off on a side tangent here with anti-virus but the main points that I want to
bring were that there are a lot of reports of FDA MAUDE, in FDA MAUDE of negative impact of
anti-virus, and that's like everything from, oh your 90-day license expired and, you know,
this is an OR situation and then this pop up is coming up saying license has expired. Everything
to bad McAfee, that's not to pick on McAfee at all, but if you recall back in 21, April
2010 this bad DAT went out and it identified a core Windows file as malicious and then all
these machines, all these XP machines just started going into a continuous reboot. So if you
were working in healthcare organization at that time you were running around manually
hitting every single box and fixing them. And just a small example is a third of the
hospitals in Rhode Island were impacted by this, so many, many people were, especially if you
were, if you have been doing this a while. There's also direct events of AV deleting,
fetal monitoring logs. >> When they actually log. >> And it's a, you know, this is a complex
issue. And then, you know, you'll have some clients or customers that push back on
vendors saying we have to run antivirus on this so the vendors are in a bad position and they
may recommend one or they may not recommend one and then the other thing they'll do often,
you'll see this in the documentation is say disable this particular feature of the
antivirus so they'll say disable on-demand scanning, which, okay, now we have this antivirus on
there. We have checked our happy check box but then we have basically hobbled a key
protection mechanism and function of this antivirus itself. So, you know, again, it
comes back to a risk basis here. What are we really trying to accomplish here? Are we just
trying to check a check box or are we trying to reduce risk because there could be cases
where, you know, many cases of why would you even want antivirus on there? But unless
you are getting it directly from the vendor you probably don't want to run it. >> So solutions
and recommendations, I'll just touch these quick, right. I mean, external attacks service
and hardening, that's important, we have obviously shown you that it's not being done
appropriately, right. Mitigate. First you need to recognize and you actually need to use a tool
like SHODAN in your organization and start recognizing those and work to mitigate them. You know,
you don't need to use SHODAN, you can the API for automation. You can, you know, use continual
monitoring, mass scan, ZMAP, those types of tools you can also use, you don't need to use
just SHODAN. You know, make the external perimeter -- (Inaudible) -- proof, we don't
see this in a lot healthcare organizations, we don't see these skill sets being employed,
because again going back to HIPAA we see compliance and information assurance driving
that budget but we need to get these skill sets in there, you need to look at it. We are
clearly showing you that we are way behind in the healthcare sector. Stop the bleeding,
right. Check and make sure SMV isn't open, as simple as it sounds. I mean look at the
exposure, look at the information attacker and get on your systems through this, it's
significant. It's your medical devices that have to do with patient safety issues. And
resilience testing, right. Red teaming. Start working on building out those programs and
really, you know, harden those devices, don't leave them wide open if you are a large
healthcare organization or any organization without any type of password so please take a look
at those. What do we need from healthcare? Kind of talked on that. You know, it's internal
programs focused on medical device security. We really need to start looking at that. You
need to start requiring security testing during your vendor selection. We'll talk about that
a little bit later and how you can implement that into your procurement, your vendor
selection process and really how do you tie that in and how do you get that inside the
healthcare organization? Well you've gotta tie it to your mission and you've gotta tie it
to patient safety. That's what the board level, that's what the executives are gonna care about.
And it definitely, when it is talking about securing medical devices, is tied to that
mission. >> So has anyone in here has ever heard of a MDS2 form? A couple folks. >> All in
healthcare who have heard of it! >> That's good. So an MDS2 form is a form that came, I think
came out of HEMS, it's been around for several years, basically it goes through some
really good, almost a checklist function. There is a place for that. About authentication and
you know, how accounts are used and big vendors, major vendors will have that form on hand for
their systems. That's something which you should be asking your vendors for and then there's
recently been some updates and addendums to that and I think that's a great form to start to
build on. And then of course you know, we need to have more responsible disclosure and then,
you know, HHS and OCR, bringing in law enforcement because this will be moving into a criminal
realm, I think. People watch "Homeland," there's a lot of sexiness of these attacks,
that's appealing to some of these demented personalities out there, so I think it's a
possibility. And now really one of the more interesting things that I've seen coming over the
past year has been some healthcare organizations are bringing in indemnification
clauses into their contracts. So what that means is you know, security and biomedical need to
get with legal in the organization and then push back on the vendors and say well, if
something you know, really bad does happen here and then who is going to own the liability on
this. >> Disclosure reporting. This is pretty easy. DHS, ICS-CERT, kind of the
agencies. Manufacturers if possible, I say if possible because this example that I'm
about to give you, they won't return any of my calls. I won't responsibly disclose it. But
they won't talk to me. Or get back to me. Apparently they haven't gotten back to DHS
either. 'Cause I have not heard anything. Healthcare organizations you know, you
probably should go to your manufacturer first, if you feel they are not responding, know
that it will take time but if you feel they are not working on it, not addressing it, you know,
we need to start looking at sending those over to ICS-CERT as well as the FDA.
Accessibility to medical devices, I think, Shawn, you can kinda talk to the stereotypical
why people don't get into research involving medical devices. >> Sure, so, you know,
they're really hard to get a hold of, right. So one of the things is you know, these are Rx
only, they're prescription only and they're also very expensive. You'r not gonna go out there and
buy you know, a radiology machine. You may not even be able to, you can't get the
permit for it you know. There's a lot of hurdles to jump on this. And then you see if you
look at the security researchers over the past years who have been working on this, they have
been hacking their own devices right, so which also brings in a whole other level of personal
ownership and credibility to this because they are not just security researchers, they're
patients. But you know, though, you can buy these off of eBay, you can go right online right
now and even though it's against eBay's technical terms of services to sell medical
devices, they sell'em on there just like you can buy you know, a fake Cisco router of off eBay,
and I've been able to do that for years. Medwow is another site. But here is the problem
with that, you know. These have already been end-of-lifed, they are recalled, it's not
current-running software so it's not really attacking you know, the actual current software.
And then the other thing is you know, there's gonna be a lot of, this is a whole ecosystem as we
continue to talk about, so there's gonna be you know, components you're gonna need to
have to get that device even up and running and get an IP network and IP address and
networked to even you know, start to develop an attack service. You want to talk about
the consulting stuff? >> Yeah, so consulting, I mean obviously, if you are not doing independent
research, and buying it, you're in a lot of cases historically you are gonna end up in NDA.
What we're starting to see, we have had a few clients that will give access to non-identifiable
data clauses so that we can talk about it openly in non-descriptive fashions so
we're starting to see that. I think there is more push to that and more coordination in
disclosure. So now Shawn kinda talked about you know, hey this is why people don't get involved
in security research. We can't get our hands on the devices. I am going to give you a use case
here that will hopefully paint the picture that you know what, you may not need your hands on
these devices but a different way to think. We need more people looking at these issues.
I can't do it by myself. So please take a look at this. One of the things is obviously
service technician manuals. They contain a lot of information that we'll show you here, full
architectural diagrams, another thing is you can always do patent searches, manufacturers
love to put all the details on their patent applications so that nobody steals their idea or
uses it. So start doing that and I'm gonna show you an example here of how that works. And it's
gonna be on the defiable right, so there's the vendor name. It's Zoll. Some specific ones on the
next series, I'll get into those later on. These are defibs, they're on the public IP space,
they sit in an ambulance, they have like a 12-vote lead and then they transmit all that back
to the ED before arrival. So here they are sitting on public IP space, they're running
Verizon 'cause they're running those other networks, well there is also a web interface, so
let's go to the web interface, right. Oh God, I need a certificate. Great. Root
certificate right on the landing page. Let's download it. Awesome security, right? Well it's also
the first defib and just out of disclosure I've never actually had my hands on this device, so
I'm doing this to paint the picture of the documentation. >> So wireless, it uses UR for
communication in these systems. The communication processor talks back to the main system
board, so that's the architectural diagram right there, so it's on the same
server, with receive and transmit. In order to import config here is your config file
out of the documention you need to import in order to change the configuration settings. All
right. What are the critical values that I need to change, what would an attacker need to
change to cause a patient harm, right? Well, these are critical values as you can see to our
logging turned off by default. Default patient mode, okay here are some values inside of those
configuration files. If I change that adult to, one is set for pediatric to adult, it's gonna
change the default like joules that are delivered from that defib. Need to do factory
resell, restore, right, it says here oh I need an authorized supervised passcode. Well, here
is how you get to it through the supervisor menu. As you can see once you get to the supervisor
menu, there's all the config settings. Many of those relate back to the critical settings
that I just showed you. So we still have the issue of how do we get into the supervisor mode.
Oh, there is your password, 1234. (Laughter and applause) So that's all you, also you can
clear logs. So you can completely wipe any traces of this happening. Before I get to
this next slide here, I need to say that I reached out to this manufacturer numerous times.
They won't return my calls. I feel I have a responsibility to disclose this. They have not
gotten back to us and so here are every one of Zoll's defib's supervisor creds for every one
of their products lines. >> AUDIENCE MEMBER: We will have your CDs by the end of the day.
>> Awesome! Here we go. There they are. Throw the CDs, there you go, 801234. So, vendors
changing, yeah, they're getting better other than that one apparently won't reach out, so.
All the baby care has reached out to us, we are working with them and I want to give a huge
shoutout here to Philips really quick. I actually went in and worked with them completely pro
bono, they invited me in to look at vulnerability disclosure and they have given me an official
statement that they are going to work on this and so this is their positioning, they're going
to come out with vulnerability disclosure policy. This is gonna be front and center for
responsible disclosure on their website so that as a researcher you can actually go record these
easily and even inside the healthcare organization so you don't have the disconnect with
Biomed. So I want to give them a big hand for that. (Applause) So look for that because other
organizations are gonna be doing that. And lastly, you know, how can you help us? If you are into
Android iOS research, we want to look at application security and mobile device security, we are
also looking with further collaboration on physicians and patients so if you're interested
in that, you can get a hold of us. Finally, last, you know, greets to all these guys, you
know, one for inspiring us, two for helping us out and collaborating with us, and you
know, the federal agencies have been great. Support has been great there as well as you know,
these two manufacturers, there's other manufacturers that are reaching out, not specifically
on this talk but it's getting a lot better. So thank you guys for coming and have a good day!
>> Thank you! (Cheers and applause)