Preroll music
Herald: Good evening, everybody. The
upcoming talk is titled "Listen to Your
Heart: Security and Privacy of Implantable
Cardio Foo" and will be delivered by e7p,
who is a Ph.D. student at the Max Planck
Institute. and Christoph Saatjohann who is
also a Ph.D. student at the University of
Applied Sciences Münster where he also
teaches security in medical devices. This
talk also be translated into German.
Dieser Vortrag wird auch simultan
übersetzt in Deutsch. And that is also the
extent of my German. I would say, e7p over
to you.
e7p: Yeah, thanks a lot for the nice
introduction. I hope you can all hear and
see us. OK, so yeah,welcome to the talk
"Listen to Your Heart: Security and
Privacy of Implantable Cardio Foo". I'm
Endres and as said I'm a Ph.D. student at
the Max Planck Institute for Security and
Privacy. My main topic is embedded
security. This topic is a funded project,
which is called MediSec. It's a
cooperation between cyber security
researchers in Bochum and Münster, as well
as medical technology researchers and
staff of the University Hospital in
Münster. And this is funded research. So
to start off, we want to give a quick
motivation what our topic is about. So we
chose these implantable cardiac
defibrillators or other heart related
implantable devices. And there are
different kinds of these, so there's lots
of other classical heart pacemakers, which
every one of you should already heard
about. Then there's also implantable
defibrillators, which have other
applications actually, and there are also
heart monitors just for diagnosis. And
yeah, as these implants are inside your
body, they pose a high risk for threats
and also they have communication
interfaces that are similar to these of
the Internet of Things. Also, we want to
talk a bit about the ethical arguments. So
when asking: Why hacking medical devices?
Well, first, the obvious thing is, yeah,
there's a long device lifecycle in the
medical sector, presumably because of the
strong regulations and required
certifications for medical products. So
it's more optimal to keep these devices as
long as possible on the market. And for
this reason, it's also sure that the, that
the, that there are open bugs from old
hardware or software and, but the
manufacturers need to know about the
issues to be able to do something about
it. That's a disclaimer for affected
patients. It's independent to the decision
for or against such a device what we talk
about. Because after all, these devices
can save your life. OK, let's get a bit
more to the details. Also we want to talk
shortly about the responsible disclosure
process. When we found out some bugs and
vulnerabilities, we informed all the, the
involved companies at least six months
ago. So from now on, it's maybe a year or.
So the companies took us serious. They
acknowledged our results and ours and
their goal is not to worry any affected
people but to improve the product
security. Vulnerable devices are or will
soon be replaced, or at least the firmware
gets updated. And yeah, whenever we do
independent security research, it helps to
keep the quality of the products higher,
which is in both ours and their interests.
And one note is, if you ever find out any
bugs or vulnerabilities in some product
please inform the companies first before
publishing anything of it online or
anywhere else. OK, let's get started into
the topic. First of all, I want to talk
about all the devices in the environment
around the implantable devices. First of
all, we have the implants himself. These
little devices, they are not so heavy.
They are placed, I think, under the skin
near the heart. I don't know. I'm not from
the medical sector, but yeah, inside the
body and they have one or multiple
contacts which electrodes connect to. And
these connect them to muscles or the
organs, and to their thing. But as there
is no outside connection for configuring
or receiving test data or something like
this or events. There is a programing
device which is usually located in the
hospital or in the heart clinics. Then
there's also a home monitoring station,
which the patient takes home and puts at
the bed table, for instance, so it can
receive all the relevant data from the
implant every day and transmit relevant
data then to the doctor. This does not
happen directly, but over the
manufacturer's infrastructure, the
structure and the transmission here is
over the internet usually. But then the
doctor can receive all the data over the
internet again, and yeah, so that's all
the four big spots where data is
transmitted to and from. And if we have an
attacker here, he could try to attack or
find vulnerabilities in any of these four
devices, as well as their communication
interfaces and protocols. OK, coming a bit
more concrete. So in total, there are
around five major vendors worldwide that
develop these implants and other devices
around them, and we look. We try to
analyze these three on top here, and yeah.
So we go a bit more in detail what we
found out and what we try to analyze here.
So going back to the implants, I already
showed it to you. That's maybe how it
looks like from the inside. Not very good
to see, I think, with the camera, but
there's also some picture in the slides.
And yeah, first of all, these implants
contain the desired functionality. For
instance, defibrillator, pacemaker, heart
recorder. And these features have
different requirements. For instance, a
defibrillator probably needs more power,
and so needs a larger battery or a huge
capacitor, for instance. And a heart
monitor doesn't need anything of these.
And of course, all of these need this
communication interface, which is realized
over radio frequency. But sometimes it's
also only over the inductive coupling,
which is maybe known from RFID. And when
looking inside these devices, we see there
are highly customized parts inside, which
means there are unlabeled chips, even
unpackaged chips that are directly bonded
onto the PCBs. So analysis is quite hard
and difficult. But all of these have in
common that there's a small microcomputer
inside that handles everything and also
the communication. Yeah. Then there are
these home monitoring units, I just get
one here, looks like these, and as I said,
they sit on the bed table and transmit the
data on a daily basis to the doctors. They
also need some wireless communication
interface to the implant. And when they
got the data, they need to transmit them
to the doctor. And this is usually done
over a mobile to mobile GSM or UMTS
network. And then the data is sent to the
manufacturer server. And compared to the
implants these are based on standard
multipurpose hardware. That means often we
will find there are Linux operating
systems and lots of debug ports of serial
interfaces or USB. So they are easily
accessible for us. OK. And then we have
this hospital programmer. They are used in
the cardiology clinics, are able to
configure the implants and also use test
modes in the implants. But also, like the
home monitoring, they can read out the
stored events or live data and. Yeah. So
they are in the heart clinic and operated
by doctors. And usually these are rented
to the hospitals or leased from the
manufacturer. But, however, we could find
out that individuals could buy these
second hand on specialized, yeah,
specialized platforms similar to eBay, I
would say, for medical devices. And now on
to our methodology when analyzing the
devices. So first of all, we thought about
goals of a potential attacker. First of
all he mainly would like to influence the
implantable device itself. And this can be
done either. This can be mostly done over
the interface that the programming device
uses, so to inject malicious firmware in
the implant could be one goal of the
potential attacker. Another goal could be
to GSM spoof the connection of the home
monitoring box and then dump some some
medical data or also privacy related data.
And yeah, when looking at the programing
device, one could also think about direct
misuse to use, for example, the test modes
already included in the device. So what
research questions do result in this? So
the first question is: What is possible
only with the direct interaction with
genuine devices, which means that is non-
invasive? And the second question is: How
secure are these in general? Like, when
also invasive attacks are allowed. And the
third question is: Can we finally
understand all communication protocols or
is this rather difficult to do? OK. So now
we look more concretely on these attack
vectors, and we do this with the devices
which we got from our partner hospital.
And yeah, to start off, we looked at the
Biotronik home monitoring unit. And what
we did there was to run a rogue GSM cell.
So we did GSM spoofing with OpenBTS. And
this allowed us to intercept data. So this
data, which we got then, was not
encrypted, so we could reveal the access
credentials. And the same credentials you
could also find out when dumping the
firmware from the microcontroller. And
this was then done over the JTAG
interface. This firmware, which we got
there, could be reverse engineered with
Ghidra, which is an open source tool for
reverse engineering. And what we found
there was also an AES cypher
implementation, which is mainly used for
authentication steps. Also, the firmware
contained the credentials and thus the
internet domain cm3-homemonitoring.de. But
according to the manufacturer, this domain
is only used as an authentication realm.
However, they were kind of surprised when
we told them that actually they are using
the same domain for other services. But I
hope they won't do this anymore. So, yeah,
this should be fine. OK. Next up is the
Medtronic home monitoring unit, the
approach there was similar to the
Biotronik home monitoring unit. What we
found there was that a spoofing attack was
not quite possible because this Medtronic
home monitoring unit uses a mobile to
mobile SIM card, which is on a intranet,
not done on an internet or a VPN, could
think about this. And so we couldn't get a
connection to the original service. And
however, we found also on a web blog post
a documented method to find out about the
encryption password because the firmware
of the device is encrypted. And, yeah,
turned out that it was a Linux embedded
Linux system, which we could also
influence when opening up and tearing down
the device. Taking out, I think it was an
SD card and then overwriting some, some
files. And here in the picture, you can
also see where we could display an image
on the screen of the device. This was done
using some DBus messages because it was an
embedded linux really. So here we've got
also the server backend addresses also in
the firmware. But more to that later. The
third device which we analyzed was this
Boston scientific programing device. You
can switch the camera so we can see it
more clearly here. Yeah. So this rather
huge device we could buy for around 2.000
U.S. dollars from this auction platform.
And we could also tear this down because
it's never used any more for real
productive cases. And there we found a
hard disk inside. And there is also a
Linux system on it, which I think is from
2002, in the slides. And the device itself
is a Intel Pentium based device, which is
designed in 2004, and the software is from
2011. So quite old, right? But yeah. So
that's I think the thing about this
device. The Linux kernel, sorry, the Linux
system in the device also contained a
window manager, the tiling window manager
and using the modifying files or shell
scripts on the hard disk allowed us to
also start the twm, the tiling window
manager on certain actions. So from there
on, we could simply open up an xterm shell
and then have root rights. OK. So maybe I
will show it in the live demonstration
later. Also, we found some region lock
configuration file, which we could also
alter to allow to connect to the radio
frequency, which implants used around the
world. And as the Linux kernel is so old,
probably further exploits are likely
possible. But the device is luckily being
replaced right now. That's what Boston
Scientific told us. One nice thing about
this device is that we found also a x86
binary, which is called "checkDongle" on
the hard disk and this checkDongle is more
binary. It just looks for direct
connections on the printer port. And when
reverse engineering the direct
connections, we could rebuild a genuine
dongle. OK. So with this dongle we were
then able to also change this RF region
setting inside the general menu of the
device, but we could also boot into either
the integrated firmware upgrade utility
over some special USB drive additionally,
or we could access the BIOS configuration
and boot from different devices. This, of
course, could leak stored treatment data
and personal data of the patients that are
stored, maybe on the hard disk itself or
later on when something is modified. OK,
so now I have prepared a little live
demonstration with this programing device.
Maybe the guys from the camera operation
can switch to the live feed from the
device itself. We will see what I see
here. And first of all, I will quickly
show how the device itself works and I
just put this antenna on one implant and
then the interrogate button leads to
starting the specific software for the
implant. As you already see the tiling
window manager also started, so when we
want to, we can start a xterm terminal and
when connected to a keyboard, we can also
type in something and we are root. Also in
this standard interface now we can access
some test modes or settings of the
implant, but I'm not really into it, so
let's skip this part when setting or doing
some stuff here. But what else we could do
now is this security dongle. I just plug
it in and then started again with an
attached flash drive. Then it starts this
normal BIOS post. And when this is done it
simply boots from this USB flash drive.
One special thing about this flash drive
is I had to find one which supports USB
1.1 because the hardware is so old. But
finally, I got it working to boot from
this USB drive. And after some while, when
loading all the data, you see, it simply
starts a FreeDOS operating system and then
starts Doom. Now we can simply play doom
on this programing device from a hospital,
so. Quite interesting, right? OK, I think
you can switch back to the slides, please.
OK. So now that was this programming
computer. What else is missing, is the
server infrastructure between the home
monitoring and the doctor. First of all,
we looked at the home monitoring access to
the manufacturer and when looking at the
credentials or rather the HTTP domain or
IP address, I don't know, in the home
monitoring system of Medtronic, we were
able to access the HTTP web server, which
the data is, I think, using a POST request
is transmitted to the server. However,
whatever we sent to the server resulted in
a blank page with the status code 200. So
no matter what we sent, right? We could
also send some really, really incorrect
data. But it doesn't matter. It just keeps
this blank page. So this seems to be a
measure against this misuse. And maybe
it's not so bad it like this. However, I
don't know if we looked for any encrypted
stuff there. Probably it's only TLS
encrypted or something. OK, and then the
doctor also gets the data from the
manufacturer server. So this is also
usually done over a Web interface, which
we learned from our partnering hospital.
And when looking around there, we thought
it's not that bad because there's a
typical login username password
authentication included. And then we
stopped there because these are productive
systems and we wouldn't want to do some
SQL injections or something like this
because it's a really productive system
and probably life-depending monitoring is
running there. So we didn't want to risk
anything. Right. So better stop there and
let it be. OK. So but from the first look,
it looked quite okayish. OK, so a quick
summary about all these findings on the
technical aspect. There are several
security vulnerabilities in different
devices. Yeah, sure, patients could be
harmed, when therapy relevant data was
manipulated. However, usually there is a
doctor in between. So whenever the doctor
gets some information that something's
wrong or something like this, and probably
he would look and find out what is wrong.
And yeah, we also found out that it's
possible to access medical devices. So,
yeah, we got this programing computer for
2.000 U.S. dollars, which clearly shows
that maybe not a good practice to simply
rent or lease these devices, but maybe
design these at most secure as possible.
And maybe some countermeasures, what can
be done to make it better? First of all,
regular software update maintenance could
resolve most of these issues. Also, it
would be nice to include some medical
professionals in a product engineering
phase, because some test modes maybe
aren't that relevant when the implant is
finally inserted in the body after
surgery, so then nobody needs these test
modes anymore, for example. And last of
all, but not least. Please make use of
state of the art cryptography and PKIs and
maybe also open protocols to improve the
security and develop something that is as
secure as it gets. OK, so this is, I
think, the technical part, and I would
like to hand over to Christoph, who will
tell us something about the GDPR request
and responses and nightmares.
Christoph Saatjohann: Yeah, thank you. So
my name is Christoph Saatjohann from
Münster University of applied sciences,
and I will tell you something about the
privaciy part, so privacy stuff, because
as you already heard, there is a lot of
data included in this complete ecosystem.
So there is some data flowing from the
implantable device to the home monitoring
service and then going farther to the
internet to the company of devices here.
Now my question was, OK, what can we do
here? How can we take a look into the data
processing here? How can we look into the
processes of the company? What would they
do with our data or with the patient data?
And we used the GDPR for this, so the GDPR
is the General Data Protection Regulation,
it was put in force in 2018. So it's not
so new. During our study it was two or
three years old. So we thought the
companies are still, are already prepared
for such stuff. Mrs. GDPR, the user in our
case, or the patient, can obtain some
information about the processed data and
with the Article 15 of the GDPR the
patient can ask about the purpose of the
processing, the categories of the data and
the recipients. So, for example, some
subcontracts who will get the data from
the patient and compute something that
just to convert it to some PDF or put it
on the web interface for the doctors. So
that's some typical part, typical tasks
for some subcontractors, so some other
recipients who will get the data. With
Article 20, it is possible to get a copy
of the data itself. The patient could ask
the company,: Yeah, please give me a copy
of all my own data. I want to look into it
or I want to move it to a different
company. And for this moving from one
company to a different company, it's
called data portability, the data must be
provided in a commonly used, machine
readable format and machine readable
format does not mean PDF, for example. For
our topic here, for the measurable things,
commonly used formats may be DICOM or HL7
and not PDF. The GDPR also defines the
maximum answer time. So every request from
a customer should be answered in a maximum
of four weeks. If it's a real complex
thing, a complex request or something like
this, it might be extended up to three
months in total , but the customer has to
be informed about the extension and also
the reasons for the extension. The last
point is said, so GDPR defines two
important roles for the following parts.
Also talk here. First is the data
controller. That means the data controller
is responsible for the complete data
process. He might want to share this data
with some other recipients or
subcontractors or subsidiaries of the
company. And then the other recipient is
called the data processor and he processes
the data. But responsible for this process
is the data controller. So the important
thing here, the data controller is
responsible. Whatever happens, he will,
yeah, he has to answer the request. So
with these GDPR, yeah, methods here, we
thought about: What can we do? And our
thing was that we acquired some patients
with some implanted devices and we sent
some GDPR inquiries in their names. It was
a company, so we told the company: OK, we
are patient xy and we want to know
something about our data and we want to
have a copy of our own data. And of
course, now you can argue, OK, now we are
handing some very sensitive medical data
here, so we have to keep our study here,
our case study itself GDPR compliant. So
we talked to our data protection officer,
told our study design here. We set up some
contracts with the patients so that we are
self GDPR compliant. Hopefully, it works
out. So no one, so we haven't got sued. So
I think that worked out. At the end we
were waiting for the answers of the
companies and the hospitals and of course,
analyze the results. So we looked on the
completeness, we thought about: This
dataset, is it complete? Or have the
companies some other data which were not
provided? We also looked on the data
security, especially: How is the data
transmitted? Do we get this via plain text
email, perhaps like ZIP files or some CD-
ROMs? So we looked on this process here,
and of course, we look on the time of the
answer. So remember, four weeks is the
maximum time. In some cases, perhaps three
months, but standard would be four weeks.
And of course, if required, we sent some
follow up queries. Yes. And, as already
said, we are some responsible researchers
here, so we also do this responsible
disclosure stuff. So we talked to the
companies and discussed some methods, some
process improvements, what can they do or
at least what should they do or must do to
be GDPR compliant. So let's take a look at
the results here, what we get from our
case study. First vendor was the Biotronik
and we sent the first inquiry to the
Biotronik subsidiary, but we learned that
we have a wrong contact. So we just took a
data privacy contact from some documents
from the hospital. But they wrote back:
Ah, sorry, we are the wrong company, where
just the sales company from Biotronik.
Please refer to the different company.
Then we wrote a second letter to the
different company. And we got an answer
after two months and, now remember, four
weeks, it's not two months, so it was
delayed. Sure. But the answer itself was
also a bit unsatisfying for us because
Biotronik told us: The device was never
connected to any home monitoring system
here, so no personal data is stored at
Biotronik. We asked the patient: Do you
ever have some of these home monitoring
devices? And he told us: No, never got
this device. So this is a classic example
of a good study design or, in this case, a
bad study design. So first of all, get
your context right. And secondly, choose
good participants of your study. So this
might be a future work item here. Perhaps
choose another different patient, perhaps.
Next company, we wrote to, was Medtronic.
You already know it from the other devices
here. And the answer was that we have to
send a copy of the ID card, so they wanted
to have an identification verification.
The GDPR does not define a really strict
method for the verification or when it is
required, when it's mandatory or when not
but in the GDPR it says, it is possible in
some cases and we think here we are
dealing here with very sensitive medical
personal data. We think this is totally
fine. So identification verification is
fine for us, and we think this is a good
thing here that they really check it, that
we are the person who is telling the
person. They also recommend us to use the
Medtronic secure email system, and first
of all, we had a good impression because
it's much better than have some plain text
email and if they are hosting some secure
email system on their servers, we said:
OK, that's a good idea, right? We have a
TLS secure connection here. Looks
perfectly fine. Let me send some tests
emails, but we saw on the email headers
that email is routed to some US servers
from the Proofpoint company in the USA.
And here we would say, OK, that's not
really good because normally if I'm a
German customer or a European customer and
sending some GDPR request to the
Medtronic, Germany or any other EU
Medtronic subsidiary, I'm not sure about
or I have no knowledge about that email is
routed through the US. And also for the
GDPR compliance we are not sure if this is
actually allowed because there are some
discussions about the Safe Harbor thing.
So that might be not really GDPR
compliant. In the least it's not good for
the user. It's a bad user experience here.
But OK, we will use this anyway, because
we think such a device, such a platform is
better than plaintext email, so we sent
our inquiry about the system. And the next
point was really surprising to us. So we
were waiting for the results. And I looked
into my yeah, we created a GMX free web
email service account for this
communication and suddenly I got an email
in this system in the GMX email. So the
response from Medtronic was not sent via
the secure channel. It was just sending in
plaintext email and we said: OK, what's
the point here? So you recommend us to use
the secure system, but they use plaintext
email. So this is a thing they really have
to change, sure. Then it goes a bit back
and forth, we wrote some emails and they
wanted to have some more information about
us. What device do we have, what serial
number and what services we use. And in
the end, we got a doc file. So a standard
Word file as attachment of an email and we
should write some information in it and
send it back. And from a security point of
view, so from our security researcher site
here, we would say that's not the best way
to do it because Doc files in the email
attachment, this is a classical use for
ransomware or phishing email. So we did
this to get the final data as a final
answer, but we would propose to change the
system here. Where we got now the final
data. And so we thought, OK, now we really
got some data now. So that's the point
where we got some really good stuff here.
But in the end, after this forth and back
and creating some accounts on some
systems, they just stated: Oh, so we were
the wrong contact. The hospital is
responsible. We are just a data controller
in this case. And of course, this was a
bit unsatisfying because we thought: OK,
we are now close to the to get the data.
But never got happened. Yeah, so
analyzizing, so in the end, in GDPR
compliant might be OK. So we are not into
this relationship between Medtronic and
the hospital. So it might be that they
have an agreement: Who is the controller,
who was responsible? We couldn't check it
as a patient, but of course, the user
experience is not good because you have so
many emails and at the end you will get
nothing. But the third one is Boston
Scientific. You know Boston Scientific
from the nice Doom device here. And we
sent an inquiry to BSC, and we got a
response that they want to have an
identification verification, so the same
as Medtronic. So we said, yeah, that's
fine, sounds legit. They said also, yeah,
you can use plaintext email. Just send an
email to this email address or you can use
our online tool and our patient chooses
the email. So from security side, we would
use a platform or a secure platform now.
But I can totally understand the patient
because it was a hard copy letter, so a
real letter by snake postal mail. And he
should type this really long link, the
long URL with some random data. And if you
type one character wrong, you have to do
it again and so on. And from the customer
point of view, so the user experience is
also very bad here. So no one wants to
really type this in your browser and see
if it's correct or not. So Boston
Scientific should use a different system
here, some short link system or just have
a short domain and a very short access
code, but something better like this one
here. But then we got an email. So it was
a plain text email, so not good, of
course, medical data via plain text email
not good. So some can now argue: OK, but
our patient started to do it. Our patient
started to wrote a plaintext email. But
the common understanding for the GDPR is
that even if the customer is asking via
plain text email, the company cannot
respond in plain text email. You have to
do something special, something secure. So
this is also a thing Boston Scientific
sure changed. But hey, we got seven PDF
reports. So our first data now in this
case study after I don't know how many
emails and letters, but we got some data.
Then we thought, OK, seven PDF reports and
the device is active for three years. That
sounds not OK, that sounds a bit, a bit
less for seven, for three years. So we
contacted the doctor, of course, with the
consent of the patient, and the doctor
looked into this online portal and saw a
lot of data, there were a lot of raw data,
a lot of PDF reports and graphs and full
of information. And so we thought: OK,
that's not enough. We got seven reports
but the system is full of any other data.
Of course, we go to BSC and tell us: OK,
we want to have all the data. BSC
apologized: OK, so we didn't look it up
into the home monitoring thing, but you
can have the data, but we need two extra
months. So, as I said in the interruption,
that might be OK if it's a really complex
thing and then it might be OK. For my, my
understanding is or I have a feeling that
they have to implement some export
mechanism to fulfill our request. But OK,
if they want to have two months and we got
the data, we were fine with this. Yeah,
and now final data. Within this extended
deadline, so they did this in the
deadline, in the three months, we got all
the data. And all the data, I mean,
really, we got a ton of it.It was a large
zip file with a lot of HL7 data. So it's a
raw, digital, machine readable format. And
we got some episode data, also digital as
an excel sheet. And we were now really
happy because this was really satisfying.
The patient, or in this case, we got all
the data which are really GDPR compliant.
So that was the first and only vendor
where we got really our GDPR request
fulfilled. Yeah, but last point, we have
to mention now the security. It was not
sent directly by email, but we just got
the download link via email. And from the
security perspective, that's more or less
the same. So if you have a man in the
middle who can read plaintext email, you
can also click on the link in the download
email. So, OK, we got the data but the
process here with the security must be
improved. We also got one hospital patient
and we send one inquiry to a hospital.
There's also some things which we were not
informed of, which we're not aware of it.
The hospital was doing the implantation of
the device in our inquiry was five years,
the hospital was bankrupt and we were told
that we have to contact a different person
of the old owner of the hospital. So the
bankrupt company. We also think that this
is in the, yeah, we also think that this
might not be correct because the
explantation of the device was done during
the time where the hospital was under the
control of the new owner, which we
contacted. So there might be some data for
the explantation. But we also write a
letter to the old company, and we got an
answer, but also after two months, so
again, here we have to wait two months. A
delay GDPR time frame was not fulfilled.
And also the final answer, so we get some,
we really got some data, as we can see
here, this handwritten stuff here, but we
were missing, for example, the surgery
report. Normally a hospital has to do a
lot of documentation for surgery, but we
didn't get this information here, so we
just get a part of it. But in summary, I
won't go into all at this point, but you
can see a lot of red here, so we had some
plaintext data via email, which is not
correct and also not legally, not GDPR
compliant. We have some deadline missed.
We have some incomplete data or at the end
it was complete data, but we have to ask a
lot and have to ask a doctor who will
double check if the data is correct and we
needed often more than one request. And
finally, for the patient, if you want to
have your data, if you want to execute
your right, it's a really hard way, as you
can see here. And you need a lot of
emails, a lot of time for this. And
sometimes it's not really possible because
they say: OK, just go to the hospital, go
to a different thing here. We are not
responsible for this. So it's not a good
user experience here. And our
recommendation for the companies is and
also for the hospitals, they should be
prepared for such stuff because GDPR is
now active for more than three years. And
in the next time or some time, they will
get some requests and perhaps not from the
friendly researchers but from real
patients. And they can, yeah, if they
won't get the answer, they can go to the
local authorities and the local
authorities can really,can sue them so
they can punish the company with a large
fine. So our recommendations: Be prepared
for such stuff. And with this slide, I
want to thank you for your attention and
want to close the talk, and we are happy
to answer some questions in the Q&A
session. Thanks.
Herald: Thank you very much. I have a
bunch of questions from the internet.
First one is, did you analyze binaries
only or did you have any access to source
codes? And did you ask any
manufacturers...
e7p: Please repeat the question. I didn't
get it because of...
Herald: Some technician, please mute the
room. I can also (inaudible) Ah, the
question is: Did you analyze binaries only
or did you obtain a degree of access to
the source codes?
e7p: I'm not sure if the check dongle is
meant but for this one, it was very small
and we could analyze it easily using
Ghidra to decompile it and then just see
which data needs to be which position in
the parallel port. If that was the
question. I think the other binaries from
the home monitoring system or, if you
could concretize... From the home
monitoring systems, we first had just a
look for strings mainly, for some access
credentials or domain names. And I think
we did not that much the decompilation in
the other stuff, but the whole software of
the programing computer is in obfuscated
Java. And this is, I don't know, it's a
just in time compiled obfuscated Java, and
I didn't find a good way how to do with
this. Other questions?
Herald: Thank you. Another question was:
How many CVEs did you file from this
research?
e7p: So I'm not sure, but some of these
findings were already found by others, and
we just didn't get that they were already
reported as CVE or as CISA reports. But I
think one or two or three.
Christoph: Yes, there were some CVEs and
also our results were linked to some other
CVEs which were already published. The
company did some other internal research
thing and internal research got some CVEs.
But if you look into the CVE, you cannot
always make it back to the actual
vulnerability. But at least for the
programmer here, for the Boston scientific
programmer there was the CISA advisory and
a few months back, I think in September or
just end of August, there was a CISA
advisory for this programmer and it
stated, I don't know, four or five CVEs.
Yeah, and it will be replaced in the next,
yeah, hopefully months, because it's also
pretty old. And it's the old generation
and the hospitals have to use the newer
generation in the next months.
Herald: You mentioned the cooperativeness
of the manufacturers on the subject access
request but how cooperative were they on
the technical side, when you tried to
report and disclose?
e7p: Yeah, actually, they were quite
cooperative when we simply wrote: Hey, we
found this and that. We wrote it to them,
I think, first at the press address or
something. And then we were redirected to
the internal security group, or, would you
say, the experts. And then we had, I
think, Zoom meetings with them and it was
a good cooperation, I would say.
Christoph: Really, I think it was a good
communication on the same level here, so
it was really the goal from all that we,
of course, don't threaten the patients,
but get the product more secure. I think
it is also some point of regulation like
the CISA in the US. If they have
vulnerabilities they have to change it so
they also get some pressure from the
regulations and they really want to change
some things. So that's my impression and
the discussions were really well
organized, well structured with a lot of
people who were really deep into the
topic. So we asked some questions and we
got really deep insights into the products
here. They were very helpful.
e7p: So I think all of the companies
offered some jobs for security analysts.
Christoph: Oh yeah!
e7p: So anyone who's interested in jobs at
Boston Scientific or Medtronic or
Biotronik must...
Christoph: Just hack a device and you will
get a job for it. I don't know.
Herald: And the last question I have for
you is how difficult this was in terms of
technical skills needed. Was this, did it
require really high tech exploits or was
this just unbelievably easy? How, where in
the spectrum was it?
e7p: So with the programing device it was,
for me, rather difficult because I'm not
so much into 90s or 2000s PC architecture,
so I did have to learn something and I
found out about old custom hardware which
is interacting over PCI and also with the
home monitoring I had to learn some stuff
for embedded Linux and find out where the
network stack is and how it all works, but
all in all, I think in maybe one month or
something like this, I could have done it
all in all. And to find out.
Christoph: I mean, it actually depends on
your knowledge already. So some stuff were
pretty standard like sniffing on some
busses on the hardware with a logic
analyzer. If you did this in past, you can
also do this on these devices, for
example. But if you never did this, then
you have to figure out which pins are for
which bus, how can I identify which bus is
used here? How can I read out the EPROM?
How can I read out the memory chips? It
highly depends on your previous work and
previous knowledge. For Endres here it's
easy. laughs
e7p: laughs Maybe not.
Herald: OK, thank you. I think this
concludes the session. Thank you both for
this interesting presentation. So we'll
see how your research will be further
approved.
e7p: Thank you. Thanks for being here.
Christoph: For being remote there. And
next time, hopefully in life and presence,
hopefully.
Herald: Yes, that would be so much better
than this. Bye bye.
postroll music
Subtitles created by c3subtitles.de
in the year 2021. Join, and help us!