Listen to Your Heart: Security and Privacy of Implantable Cardio Foo

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!