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!