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!