1 00:00:00,000 --> 00:00:18,380 *35c3 preroll music* 2 00:00:20,130 --> 00:00:27,630 Herald: So, Dennis, the left speaker, finished his M.Sc. in IT security this 3 00:00:27,630 --> 00:00:33,180 year. The next talk is based on his master thesis, InternalBlue, which is a Bluetooth 4 00:00:33,180 --> 00:00:38,700 experimentation framework for which he even received a prize. Jiska, the right 5 00:00:38,700 --> 00:00:45,229 speaker, or for you left speaker, has been his supervisor during the thesis and she 6 00:00:45,229 --> 00:00:49,969 loves breaking things. After several talks about wireless security, software-defined 7 00:00:49,969 --> 00:00:55,199 radio and Fitbits, she is now talking about Bluetooth. Please welcome on stage 8 00:00:55,199 --> 00:01:00,219 Dennis Mantz and Jiska Classen to their talk "Dissecting Broadcom Bluetooth". 9 00:01:00,219 --> 00:01:06,941 *Applause* Dennis: Yeah. Thank you for the 10 00:01:06,941 --> 00:01:10,740 introduction and welcome you all to our talk. I'm Dennis and as said I choose 11 00:01:10,740 --> 00:01:16,810 Bluetooth as the topic for my master's thesis and the outcome basically was I 12 00:01:16,810 --> 00:01:19,990 reverse engineered the firmware of a Bluetooth controller which was 13 00:01:19,990 --> 00:01:24,039 manufactured by Broadcom, and I built a little experimentation framework around 14 00:01:24,039 --> 00:01:27,950 it. And today we are not only going to present the framework, but also various 15 00:01:27,950 --> 00:01:33,130 kinds of use cases around it, and we also brought along some demos. Now, if you 16 00:01:33,130 --> 00:01:37,409 start such a big reversing project you certainly know that this will not be an 17 00:01:37,409 --> 00:01:41,659 easy task and also quite time consuming. So you might want to ask: why did we do 18 00:01:41,659 --> 00:01:48,539 that in the first place? So there are several good reasons. For one, dissecting 19 00:01:48,539 --> 00:01:53,350 the firmware and exploring it for reverse engineering is really helpful if 20 00:01:53,350 --> 00:01:56,890 you want to get insights from a security perspective. And this is what I had in 21 00:01:56,890 --> 00:02:01,250 mind when I first started my thesis. But then secondly and even better, once you're 22 00:02:01,250 --> 00:02:05,819 able to modify the firmware you can actually leverage this fully featured and 23 00:02:05,819 --> 00:02:10,270 working Bluetooth implementation to be your very own experimentation platform, where 24 00:02:10,270 --> 00:02:16,480 you can add new features or can also alter existing behavior, and it almost feels 25 00:02:16,480 --> 00:02:20,800 like you can add a kind of open source touch to a closed source and proprietary 26 00:02:20,800 --> 00:02:25,950 platform which I really like about this project. Certainly this requires a certain 27 00:02:25,950 --> 00:02:31,130 background in many different departments like security, code analysis, wireless 28 00:02:31,130 --> 00:02:36,510 signals, embedded programming, and also not every researcher has resources and 29 00:02:36,510 --> 00:02:42,159 time to do such a reverse engineering project, but we think that the outcomes of 30 00:02:42,159 --> 00:02:46,709 this project are really helpful and beneficial for the security community. So, 31 00:02:46,709 --> 00:02:50,819 and last but not least we actually really like reverse engineering. So we already 32 00:02:50,819 --> 00:02:55,129 had great experiences with similar projects in the past. For example, some of 33 00:02:55,129 --> 00:02:59,090 you might know the NexMon project, where we reverse engineered and also modified 34 00:02:59,090 --> 00:03:05,960 the firmware of a Wi-Fi controller. Okay, before we show our work, we first have to 35 00:03:05,960 --> 00:03:09,879 introduce a few Bluetooth protocols which we will be mentioning quite a lot 36 00:03:09,879 --> 00:03:15,390 throughout this talk. So the first one would be the host controller interface. 37 00:03:15,390 --> 00:03:20,390 Some of you might know that, it's the HCI, and it's a protocol layer between the 38 00:03:20,390 --> 00:03:25,030 Bluetooth controller and the host system, where the health system would be for 39 00:03:25,030 --> 00:03:29,930 example an Android phone, or iOS, or Linux, or any other operating system which 40 00:03:29,930 --> 00:03:34,310 implements those upper layers of the Bluetooth protocol stack, and all the 41 00:03:34,310 --> 00:03:38,429 lower layers are actually implemented inside the Bluetooth controller. And one 42 00:03:38,429 --> 00:03:43,549 of them would be for example the Link Manager Protocol, the LMP. And this one is 43 00:03:43,549 --> 00:03:48,240 also really interesting. It actually manages connections to other remote 44 00:03:48,240 --> 00:03:54,870 Bluetooth devices. For example, pairing is also done on this protocol layer. And 45 00:03:54,870 --> 00:03:58,760 what's an interesting difference is that the Link Manager Protocol is actually 46 00:03:58,760 --> 00:04:03,540 transmitted over the air to communicate with other devices, whereas the HCI 47 00:04:03,540 --> 00:04:07,709 protocol is only used locally to communicate between the operating system 48 00:04:07,709 --> 00:04:14,180 and the Bluetooth controller. And another interesting fact to know is that the HCI 49 00:04:14,180 --> 00:04:20,269 is actually able to be observable from the host site. So if you maybe tried to capture 50 00:04:20,269 --> 00:04:24,420 on a Bluetooth interface in Linux before, or if you turned on the BT snoop log 51 00:04:24,420 --> 00:04:28,880 feature under the development settings in Android, you probably have seen HCI packets 52 00:04:28,880 --> 00:04:33,530 in Wireshark before, because this is an easy task to do. However you probably did 53 00:04:33,530 --> 00:04:37,750 not see LMP packets in Wireshark before, because this protocol layer is actually 54 00:04:37,750 --> 00:04:41,910 implemented inside the controller and it's not observable from the host side. You 55 00:04:41,910 --> 00:04:45,100 won't see those packets if you just capture on a Bluetooth interface because 56 00:04:45,100 --> 00:04:50,710 you can only see what's above the HCI layer. And so the other thing is that you 57 00:04:50,710 --> 00:04:55,310 cannot also simply sniff this from the air because Bluetooth has frequency hopping 58 00:04:55,310 --> 00:04:59,920 and encryption. So it's a lot harder to sniff those packets from the air just as 59 00:04:59,920 --> 00:05:06,890 with Wi-Fi for example. But today we try to change that. Now I will introduce the 60 00:05:06,890 --> 00:05:10,330 framework I developed and show its features, and later we go into more 61 00:05:10,330 --> 00:05:16,770 details and also present some demos. As already mentioned, we named the framework 62 00:05:16,770 --> 00:05:21,790 InternalBlue. It's open source and you can find it on GitHub and currently it's only 63 00:05:21,790 --> 00:05:26,200 compatible with the Nexus 5 if you want to use all of its features, but we are also 64 00:05:26,200 --> 00:05:30,250 working to port it to other Bluetooth chips in other smartphones, and also other 65 00:05:30,250 --> 00:05:35,990 platforms like the Raspberry Pi, and yeah, soon you will have more devices which are 66 00:05:35,990 --> 00:05:39,940 supported by this framework. We also already gave a talk where we introduced 67 00:05:39,940 --> 00:05:44,010 the framework and give some details about the internals and how it works. So if 68 00:05:44,010 --> 00:05:47,110 you're interested and want to learn more then you should check out our previous 69 00:05:47,110 --> 00:05:50,710 talk which was also recorded and you can find a link down at the bottom of the 70 00:05:50,710 --> 00:05:56,910 slide as well. Basically in a nutshell we use vendor specific HCI commands which are 71 00:05:56,910 --> 00:06:01,900 implemented by Broadcom and allow us to read out and modify the firmware while the 72 00:06:01,900 --> 00:06:06,580 chip is actually running. And on top of this, we basically implemented a Python 73 00:06:06,580 --> 00:06:11,870 API to interact with the firmware, and we use this API to then implement all kinds 74 00:06:11,870 --> 00:06:16,680 of features which we find interesting. For example one of the first things we did was 75 00:06:16,680 --> 00:06:22,590 implementing such a LMP monitoring mode so that we can finally see LMP traffic on our 76 00:06:22,590 --> 00:06:27,490 laptop in Wireshark. And what comes along with this is that we are also able to 77 00:06:27,490 --> 00:06:32,610 inject arbitrary LMP packets inside existing Bluetooth connections. And this 78 00:06:32,610 --> 00:06:36,340 turned out to be also very interesting because then we can test how other devices 79 00:06:36,340 --> 00:06:40,770 react to maybe packets they don't accept or yeah, at least it's very good for 80 00:06:40,770 --> 00:06:45,400 experimentation and for example we use this to write a little proof of concept 81 00:06:45,400 --> 00:06:50,280 script for the fixed coordinate invalid curve attack that was released this 82 00:06:50,280 --> 00:06:54,020 summer, not by us but by other researchers, and we were able to actually 83 00:06:54,020 --> 00:06:59,190 prove that other devices are vulnerable to this attack. So this is a really helpful 84 00:06:59,190 --> 00:07:06,880 and practical tool. Also, at some point we found a crash our own. So we found back in 85 00:07:06,880 --> 00:07:12,030 some older Broadcom firmwares which allows us to remotely crash the firmware in some 86 00:07:12,030 --> 00:07:17,440 of the Broadcom chips, and in some cases we are even able to execute a limited set 87 00:07:17,440 --> 00:07:21,440 of functions, so this might be even more interesting than just a crash - but more 88 00:07:21,440 --> 00:07:27,640 on that later. Now if you first start with the main thing about this is, how do we 89 00:07:27,640 --> 00:07:33,090 actually modify the firmware, How is patching being done? And I already said 90 00:07:33,090 --> 00:07:37,740 that Broadcom uses those vendor-specific HCI commands. To read them out, they are: 91 00:07:37,740 --> 00:07:42,180 READ_RAM, WRITE_RAM and LAUNCH_RAM, and they do exactly what you think they would 92 00:07:42,180 --> 00:07:46,560 do. So basically we are able to read and write in the address space of the 93 00:07:46,560 --> 00:07:50,840 firmware, and also to execute arbitrary code snippets in the context of the 94 00:07:50,840 --> 00:07:55,530 firmware. And this is pretty powerful. Broadcom actually uses this to do their 95 00:07:55,530 --> 00:08:01,310 firmware updates, so they ship so- called HCD files, which are files that 96 00:08:01,310 --> 00:08:05,030 contain firmware updates. If you have a Broadcom chip inside your laptop or inside 97 00:08:05,030 --> 00:08:08,750 your phone, you should find such a file with the extension ".hcd" on your 98 00:08:08,750 --> 00:08:13,620 filesystem, and those files actually contain just a sequence of those commands 99 00:08:13,620 --> 00:08:18,150 to upload all the changes and patches, and they're even able to do temporary patches 100 00:08:18,150 --> 00:08:23,750 to the ROM of the firmware by another mechanism that they call "Patchram." We also 101 00:08:23,750 --> 00:08:28,340 had to reverse engineer this and now we are finally able to do all those patching 102 00:08:28,340 --> 00:08:34,570 ourselves. Now, what is also interesting is that those files, the .hcd files, are 103 00:08:34,570 --> 00:08:38,890 neither encrypted nor signed. So it's quite easy to actually modify them once 104 00:08:38,890 --> 00:08:42,839 you understand how they work. And also the firmware itself on the controller is not 105 00:08:42,839 --> 00:08:47,839 obfuscated. So there are basically no major attempts done by Broadcom to prevent 106 00:08:47,839 --> 00:08:53,040 anyone to reverse engineer and modify this firmware. Currently, we write our 107 00:08:53,040 --> 00:08:57,519 code and assembler, so we write assembler patches, but we're working on including 108 00:08:57,519 --> 00:09:02,720 this in our NexMon project to finally be able to write patches in C code, which 109 00:09:02,720 --> 00:09:07,860 will be more comfortable and portable. First of course we have to do the 110 00:09:07,860 --> 00:09:10,860 reversing. Jiska: Yeah. So as Dennis told you the 111 00:09:10,860 --> 00:09:15,060 code is not obfuscated but there is no strings and no function names. So you end 112 00:09:15,060 --> 00:09:20,140 up with thousands of functions that just have no name, it's just sub 1, sub 2, sub 113 00:09:20,140 --> 00:09:25,020 some-thousand something. And then there is a tool that I used which is called CodeCut 114 00:09:25,020 --> 00:09:32,769 to try to separate those functions into modules. But also the modules don't really 115 00:09:32,769 --> 00:09:36,250 tell you that much because the problem is: then you have hundreds of modules and then 116 00:09:36,250 --> 00:09:41,720 you know which modules are central and you might to start reversing but it's not 117 00:09:41,720 --> 00:09:45,590 really fun. You have 2800 pages of Bluetooth standards, you might have some 118 00:09:45,590 --> 00:09:51,579 parameter checks in there, so you have bounds which the parameters should be in, 119 00:09:51,579 --> 00:09:55,860 and then you search for those numbers again in assembly code and you might find 120 00:09:55,860 --> 00:10:00,500 some matches and then you have concrete functions. So that's what we both did for 121 00:10:00,500 --> 00:10:08,790 months. staring at standards, staring at the code. Then people asked me: "Yes, 122 00:10:08,790 --> 00:10:15,019 that's not nice, but does it work on on recent devices?" And now the problem is 123 00:10:15,019 --> 00:10:20,450 even the Nexus 6P has a firmware from end of 2014. So I just decided to buy a 124 00:10:20,450 --> 00:10:24,899 development board, which has also a slightly outdated firmware, I mean just 125 00:10:24,899 --> 00:10:31,300 one year old. Meanwhile, this part of Broadcom was acquired by Cypress so it's 126 00:10:31,300 --> 00:10:37,250 called Cypress. But it doesn't matter, it's still the same mechanisms in there. 127 00:10:37,250 --> 00:10:42,040 And I was able to use the same HCI commands, so I can still modify the 128 00:10:42,040 --> 00:10:48,950 firmware on this, I can extract the firmware, and actually I just got that on 129 00:10:48,950 --> 00:10:56,050 December 6, and 3 days later I had all function names because somewhere someone 130 00:10:56,050 --> 00:11:03,539 forgot a patch.elf with all function names in the development kit. So that's 11 000 131 00:11:03,539 --> 00:11:09,439 function names, 3000 object names. Nice. Yeah. 132 00:11:09,439 --> 00:11:17,680 *Applause* J: So, buy development kits earlier. 133 00:11:17,680 --> 00:11:23,420 *Laughter* D: OK. Let's get closer to the first demo. 134 00:11:23,420 --> 00:11:26,589 So as mentioned we have this Link Manager Protocol which does interesting things 135 00:11:26,589 --> 00:11:30,720 like pairing and all kinds of stuff. And it's implemented in the firmware so we 136 00:11:30,720 --> 00:11:34,599 cannot really see it from outside, we cannot capture it in Wireshark. And we 137 00:11:34,599 --> 00:11:37,990 wanted to change that. So we wrote a patch that will actually hook some of the 138 00:11:37,990 --> 00:11:42,699 functions inside the firmware, those that are handling LMP, to actually forward all 139 00:11:42,699 --> 00:11:47,209 the traffic over the HCI interface back to our Android phone. And then on the Android 140 00:11:47,209 --> 00:11:50,529 phone we use a Android Bluetooth stack which has debugging features compiled into 141 00:11:50,529 --> 00:11:56,640 it so that we can also forward all the HCI traffic via TCP to our host computer. And 142 00:11:56,640 --> 00:12:00,350 from there we can then show it in Wireshark. We use a custom LMP dissector 143 00:12:00,350 --> 00:12:05,129 plugin which we borrowed from the Ubertooth project. And yeah, that's it. We 144 00:12:05,129 --> 00:12:11,100 have a LMP monitor mode. I will show that in just a second. We also have an LMP 145 00:12:11,100 --> 00:12:15,959 injection mode, so we can simply invoke functions inside the firmware. And so we 146 00:12:15,959 --> 00:12:20,410 can also invoke the function which actually sends LMP packets to other 147 00:12:20,410 --> 00:12:25,490 devices which are connected to our Nexus 5. And so, yeah, with this we have both 148 00:12:25,490 --> 00:12:30,660 channels of the communication and can actually send arbitrary traffic to other 149 00:12:30,660 --> 00:12:38,790 devices. So, for this let's go into a command line and start the framework. The 150 00:12:38,790 --> 00:12:43,620 framework has a command line interface we can use all of its features and interact 151 00:12:43,620 --> 00:12:50,070 with the firmware and to start a monitor mode, I can just type this command which 152 00:12:50,070 --> 00:12:55,329 will start a Wireshark instance and also install all the patches which we need into 153 00:12:55,329 --> 00:13:01,079 the firmware of the phone. Now from this time on, we actually have all LMP traffic 154 00:13:01,079 --> 00:13:06,060 forwarded and shown in the Wireshark frame, but currently we don't have a 155 00:13:06,060 --> 00:13:17,379 Bluetooth connection, that's why you don't see anything. Ok. Yeah, so we still need a 156 00:13:17,379 --> 00:13:22,990 Bluetooth connection, right? I could just pair those devices to create a connection 157 00:13:22,990 --> 00:13:27,680 and then we would see LMP traffic, but I want to show something else. So this will 158 00:13:27,680 --> 00:13:31,089 be a combined demo actually, because Bluetooth has some more interesting 159 00:13:31,089 --> 00:13:36,559 features which maybe not everyone knows - at least for me that was a surprise when I 160 00:13:36,559 --> 00:13:42,309 first learned about this. So even if your device is not being set to be discoverable 161 00:13:42,309 --> 00:13:46,900 by other devices, it still accepts connections from any other device, the 162 00:13:46,900 --> 00:13:51,740 other device just needs to know your MAC address and can simply connect to you, 163 00:13:51,740 --> 00:13:56,240 without even being paired before, you don't even notice this because the device 164 00:13:56,240 --> 00:13:59,540 does not have to trigger the pairing process, and then the user won't be 165 00:13:59,540 --> 00:14:03,749 notified. And so by just finding out the MAC address of any other device I can 166 00:14:03,749 --> 00:14:09,160 connect to it on this LMP layer and start communicating with it. And finding out the 167 00:14:09,160 --> 00:14:13,240 MAC address is also not that hard. There was another talk which we mention down on 168 00:14:13,240 --> 00:14:17,009 the bottom of the slide, it's called "Bluetooth smells like chicken" by Dominik 169 00:14:17,009 --> 00:14:20,809 Spill, Michael Ossmann and Mark Steward, which shows that this is actually possible 170 00:14:20,809 --> 00:14:28,430 and not hard to do. So, I can actually just type "connect" and give it the MAC 171 00:14:28,430 --> 00:14:33,570 address of another phone. J: We need again... ah great. 172 00:14:33,570 --> 00:14:37,829 D: Yes. Perfect! On the right side you actually see a Nexus 6P, which will be our 173 00:14:37,829 --> 00:14:44,189 target. You can hopefully barely read the MAC address which is shown there on the 174 00:14:44,189 --> 00:14:48,430 left side as the Nexus 5 which is the phone we use for for testing like the 175 00:14:48,430 --> 00:14:54,920 phone which is connected to my laptop here and is used for InternalBlue. And as you 176 00:14:54,920 --> 00:14:58,789 also can see the Nexus 6P is currently not in the Bluetooth menu, so it's not 177 00:14:58,789 --> 00:15:04,920 actually discoverable by by means of Bluetooth. I still can connect to it when 178 00:15:04,920 --> 00:15:10,879 I actually type "connect" and the MAC address this might may take a few ... no 179 00:15:10,879 --> 00:15:16,110 it worked directly, perfect. So now we can see that we actually have traffic on the 180 00:15:16,110 --> 00:15:20,279 LMP layer. What you also might notice that that on the Nexus 6P there wasn't 181 00:15:20,279 --> 00:15:23,800 anything. So the user didn't notice, but I have an established connection to this 182 00:15:23,800 --> 00:15:28,620 other phone and you can see the LMP traffic which is going on on this protocol 183 00:15:28,620 --> 00:15:33,370 layer. As you can see it is quite a lot: There are feature requests, version 184 00:15:33,370 --> 00:15:39,519 requests, also name requests so that the phones know how the name of each other is. 185 00:15:39,519 --> 00:15:44,269 And yeah, from now on I can also try to inject arbitrary LMP packets. For 186 00:15:44,269 --> 00:15:49,379 example I can send an LMP packet with code "01" which would be a name request and ask 187 00:15:49,379 --> 00:15:55,259 for a name at offset 0. And you should see that the name request has popped up here 188 00:15:55,259 --> 00:16:01,290 and the other device even answered with its name. If you scroll down here should 189 00:16:01,290 --> 00:16:07,559 at some point see that we have the name "Nexus 6P" because we don't renamed our 190 00:16:07,559 --> 00:16:11,619 devices. But I can also send arbitrary LMP packets so I'm not bound to 191 00:16:11,619 --> 00:16:15,089 anything that is in the specification. J: You already got the detach! 192 00:16:15,089 --> 00:16:20,339 D: So the other device actually detached which happens from time to time ... can 193 00:16:20,339 --> 00:16:22,339 reconnect. J: If we don't do anything in between we 194 00:16:22,339 --> 00:16:26,990 will get a detach from the other device because we didn't do a paring or something 195 00:16:26,990 --> 00:16:31,879 so we re-established connection. And now Dennis is going to send something that is 196 00:16:31,879 --> 00:16:36,400 not specified ... just an LMP 99. D: So it's even saying here this is 197 00:16:36,400 --> 00:16:40,480 unknown. But as you can see the payload is actually sent and the other device 198 00:16:40,480 --> 00:16:45,470 correctly answers with "this is not accepted and I don't want this". But you 199 00:16:45,470 --> 00:16:48,670 can probably see that this is very interesting for a security researcher, 200 00:16:48,670 --> 00:16:52,480 because now he can see how the other device happens in certain conditions, if 201 00:16:52,480 --> 00:16:57,760 you send them certain packets. Yeah. Quite nice to actually experiment with. OK. I 202 00:16:57,760 --> 00:17:02,879 think that's it for the first demo. Let's stop this and go back to this. 203 00:17:02,879 --> 00:17:06,590 J: I don't need the in-screen anymore. Yeah. Great. Okay. 204 00:17:06,590 --> 00:17:14,760 *Applause* D: Thank you. 205 00:17:14,760 --> 00:17:17,940 J: Another thing in the Bluetooth standard is that you need a possibility to pair 206 00:17:17,940 --> 00:17:23,380 devices, which have no input and no output capability, so they cannot show a PIN and 207 00:17:23,380 --> 00:17:29,890 you cannot enter a PIN. And this is the standard for any headset. But also a Man- 208 00:17:29,890 --> 00:17:35,670 in-the-Middle can change the input/output capabilities and then you might just get 209 00:17:35,670 --> 00:17:41,480 displayed this "yes/no" pairing without a PIN request. Even though your smartphone 210 00:17:41,480 --> 00:17:48,580 could show more than this. And I have a demo video again of the same thing. That's 211 00:17:48,580 --> 00:17:53,000 this one. So on the left hand side I have again a Nexus 5 on the right hand side I 212 00:17:53,000 --> 00:17:59,680 have an iPhone and I am pairing them. I just changed the request and the 213 00:17:59,680 --> 00:18:04,030 capabilities that it's, that I'm not having input output capability. So you can see on 214 00:18:04,030 --> 00:18:09,180 the right hand side on the iPhone it's just showing this "yes/no" question. And 215 00:18:09,180 --> 00:18:12,560 on the left hand side you still have the same algorithm which just does the same 216 00:18:12,560 --> 00:18:21,460 thing. So pairing will succeed, there's the same cryptographic routines but you 217 00:18:21,460 --> 00:18:24,750 are not being warned on the iPhone and that's a bit critical. So the standard is 218 00:18:24,750 --> 00:18:30,150 not saying: "Please warn the user to check if the other phone really has no input 219 00:18:30,150 --> 00:18:34,912 output." So I just say pair and it pairs. 220 00:18:38,051 --> 00:18:45,180 Yup. *Applause* 221 00:18:46,260 --> 00:18:49,432 So far that's only things that are as 222 00:18:49,432 --> 00:18:55,741 they are in the standard, so it's not too surprising. So the question is: Can we 223 00:18:55,741 --> 00:19:02,550 find more bugs? Yeah. Finding bugs in Bluetooth. Actually I didn't even want to 224 00:19:02,550 --> 00:19:06,170 find bugs in the beginning, I just wanted to understand how everything works. So I 225 00:19:06,170 --> 00:19:11,860 went through the handlers and I checked the... there's these checks of the 226 00:19:11,860 --> 00:19:15,810 parameters, so there is a parameter check in the beginning of each handler that 227 00:19:15,810 --> 00:19:21,330 shows me a bit which handler it could be according to the standard. And suddenly 228 00:19:21,330 --> 00:19:26,130 there is a handler which does not have any check. So there's just the missing "if" 229 00:19:26,130 --> 00:19:30,960 somewhere. And then I compared to firmware versions that I had and found out they 230 00:19:30,960 --> 00:19:39,540 silently patched that already some time between June 2nd and August 19th in 2014. 231 00:19:39,540 --> 00:19:44,960 But they never updated older devices, so they never shipped an .hcd-patch. So I 232 00:19:44,960 --> 00:19:48,860 contacted Broadcom and said: "Yeah you have a problem!" and they said "No, we 233 00:19:48,860 --> 00:19:53,320 don't." And I said: "You really have a problem there." And so on... And then they 234 00:19:53,320 --> 00:19:58,270 said: "It doesn't exist." And then I showed them more and then they said "Yeah 235 00:19:58,270 --> 00:20:01,900 ok, but it's not compliant to the standard what you're doing!" 236 00:20:01,929 --> 00:20:08,515 *Laughter* *Applause* 237 00:20:08,515 --> 00:20:11,650 I'm sorry, my next exploit will be standard complaint. 238 00:20:11,650 --> 00:20:14,780 *Laughter* And then we discussed a bit more and then 239 00:20:14,780 --> 00:20:18,000 they said: "It does not affect Wi-Fi performance." Well, in my tests it did... 240 00:20:18,000 --> 00:20:23,680 whatever... doesn't matter. So basically you can switch off Bluetooth on another 241 00:20:23,680 --> 00:20:29,590 device and then Bluetooth restarts typically depending on configuration. And 242 00:20:29,590 --> 00:20:34,350 as Broadcom didn't tell me much about this I started testing out things on my own. So 243 00:20:34,350 --> 00:20:38,130 which devices actually still have a firmware that is affected in their 244 00:20:38,130 --> 00:20:46,540 Broadcom chip? It's quite a lot. So it's like the iPhone 6, MacBook Pro from 2016, 245 00:20:46,540 --> 00:20:51,270 of course my Nexus 5, Raspberry Pi 3 and so on. And this list is really not 246 00:20:51,270 --> 00:20:55,640 complete this is just like, I asked my students: "Can I test your smartphone?" 247 00:20:55,640 --> 00:20:59,700 Some of them said: "No. Are you crazy?!" *Laughter* 248 00:20:59,700 --> 00:21:06,590 And that's the list I got just during the last weeks. And this is the one I'm going 249 00:21:06,590 --> 00:21:12,680 to demo. I just named it BT-B-g0ne, so you can kill the Bluetooth of annoying songs 250 00:21:12,680 --> 00:21:22,620 or something. *Applause* 251 00:21:22,620 --> 00:21:33,730 So I need to go into the Bluetooth here, yeah, screen-in-screen... That's great. I 252 00:21:33,730 --> 00:21:38,000 even had a "Bluetooth is not real" and so on. That's really great. What is going on 253 00:21:38,000 --> 00:21:39,430 here. D: OK. 254 00:21:39,430 --> 00:21:44,420 J: Yeah let's go for the demo. So first we are going to patch the Nexus 5 with our 255 00:21:44,420 --> 00:21:50,550 funny attack and then just press enter and now it takes a while until the the iPhone 256 00:21:50,550 --> 00:21:54,790 is realizing like "Oops my Bluetooth is gone." So if I'm playing music you will 257 00:21:54,790 --> 00:21:58,530 see it faster, the music would already stop playing. Let me just enter another 258 00:21:58,530 --> 00:22:01,949 time. Just... Yes, and there it's gone! Oops! 259 00:22:01,949 --> 00:22:08,920 *Applause* 260 00:22:08,924 --> 00:22:10,974 And then it appears again and so on I can 261 00:22:10,974 --> 00:22:14,940 just do it again and again and again. And it's actually so fast that the other 262 00:22:14,940 --> 00:22:20,070 person could not play music, because music also stops playing after this disconnect. 263 00:22:20,070 --> 00:22:25,440 Yeah that's the demo. Now we were wondering, yeah, what is actually 264 00:22:25,440 --> 00:22:31,490 happening. So actually that the crash - the crash is the best case. So there is a 265 00:22:31,490 --> 00:22:37,380 handler. I call it "Handler A", because I'm not leaking the actual problem here. 266 00:22:37,380 --> 00:22:43,180 Broadcom didn't fix it yet. So there is this handler which just should take, let's 267 00:22:43,180 --> 00:22:50,110 say, two arguments or something. But it doesn't check the parameter range and the 268 00:22:50,110 --> 00:22:55,830 compiler likes to put one handler after the other. And then we just go into the 269 00:22:55,830 --> 00:23:01,530 next handler, and so we have something like 250 functions that we can call from 270 00:23:01,530 --> 00:23:06,540 the next handler but with wrong parameters. So it's a bit buggy, and 271 00:23:06,540 --> 00:23:12,990 sometimes if a function expects to get other parameters it just crashes. But 272 00:23:12,990 --> 00:23:18,500 otherwise we can execute functions. And on the Nexus 5 we looked a bit more into this 273 00:23:18,500 --> 00:23:23,790 and I found out that I can enable test mode. So test mode should be something 274 00:23:23,790 --> 00:23:28,640 only locally to be enabled on a phone if you have root access to the driver and 275 00:23:28,640 --> 00:23:32,450 then you tell the driver: "I'm now going to test your frequencies and so on please 276 00:23:32,450 --> 00:23:35,529 go in test mode." But I can now do this remotely. 277 00:23:37,010 --> 00:23:42,996 *Applause* 278 00:23:43,230 --> 00:23:45,220 So I didn't bring this one as a live demo. 279 00:23:45,220 --> 00:23:49,358 I mean I have a HackRF with me, we can do that during Q and A, because the problem 280 00:23:49,358 --> 00:23:52,910 is there is probably too much going on in the spectrum here and you wouldn't see the 281 00:23:52,910 --> 00:24:01,150 test mode starting anyway. So I'm just doing the attack and then on the left hand 282 00:24:01,150 --> 00:24:04,330 side, I just took a quick pause, you can see the test mode, so that's just the 283 00:24:04,330 --> 00:24:09,690 default test mode hopping around in all channels. The packets now appear a bit out 284 00:24:09,690 --> 00:24:15,170 of order because I just put them into a queue, send them. This "???" payload is 285 00:24:15,170 --> 00:24:19,910 the malicious payload. I just send "test_control" and "test_activate". And 286 00:24:19,910 --> 00:24:28,120 first they get this not_accepted. And then after this "???" payload you can see that 287 00:24:28,120 --> 00:24:32,510 it's accepted. And on the left hand side you can still see that there is the test 288 00:24:32,510 --> 00:24:39,977 mode going on, so really block things for longer time. And then it's accepted, magic! 289 00:24:42,448 --> 00:24:48,648 *Applause* 290 00:24:48,860 --> 00:24:52,330 If you combine this with disabling adaptive frequency hopping you can even 291 00:24:52,330 --> 00:24:58,080 force the other device, which is also then in test mode, to stop hopping for a while 292 00:24:58,080 --> 00:25:02,880 and then just jam a selected frequency, so you could also jam a selected Wi-Fi 293 00:25:02,880 --> 00:25:07,750 frequency that this device is currently using. And it's a combo chip, so you would 294 00:25:07,750 --> 00:25:13,360 really be on the same antenna. We can confirm this works on Nexus 5 and Xperia 295 00:25:13,360 --> 00:25:18,950 Z3, because they both have to be same BCM4339 chip. It might also work on other 296 00:25:18,950 --> 00:25:24,630 devices with that chip. It's a bit random to find out what is in there. You need to 297 00:25:24,630 --> 00:25:31,740 find teardowns and on. So when finding this bug we started developing a 298 00:25:31,740 --> 00:25:37,720 toolchain. So Dennis added a feature for tracepoints. You can add now a tracepoint 299 00:25:37,720 --> 00:25:41,410 to a function which is then called once and dumps all the registers and the stack 300 00:25:41,410 --> 00:25:47,650 and heap. I then fed this into an emulation framework, which is currently 301 00:25:47,650 --> 00:25:52,510 quite slow with unicorn and radare2, but I get a full call trace, which is very 302 00:25:52,510 --> 00:25:56,960 nice to look at. So I have an idea what is going on, what is changed in the memory. 303 00:25:56,960 --> 00:26:01,171 And I currently have a student working on a qemu/gdb set up, which is faster but 304 00:26:01,171 --> 00:26:06,870 producing less output, just to fuzz more efficiently. However, you get really a lot 305 00:26:06,870 --> 00:26:11,060 of output that we weren't able to completely analyze yet, so there's 306 00:26:11,060 --> 00:26:19,580 probably more. Maybe tell you somewhen later. Now you need to somehow fix that 307 00:26:19,580 --> 00:26:23,050 bug. And that's that's really a problem, and that's also why I didn't tell you the 308 00:26:23,050 --> 00:26:29,200 exact payload that is causing these issues. Because, well, the fix would be in 309 00:26:29,200 --> 00:26:33,880 one of those .hcd-files. It would be plaintext. It would not be signed and it 310 00:26:33,880 --> 00:26:38,750 would just tell you directly "This handler is vulnerable in exactly this position!" 311 00:26:38,750 --> 00:26:44,080 and so on. The patch is just 14 bytes, but you need to install it and then it's easy 312 00:26:44,080 --> 00:26:48,720 to understand what it does, right? So I had an idea: Let's do some more generic 313 00:26:48,720 --> 00:26:54,390 fix. So what I planned to do was having a generic filter, filtering some packets 314 00:26:54,390 --> 00:26:58,270 like that you won't reply to, pings connection establishments and so on, to 315 00:26:58,270 --> 00:27:04,800 untrusted devices. And then just over Christmas I started testing that one with 316 00:27:04,800 --> 00:27:10,650 bigger setups, with more phones and so on. And then I realized: OK if I throw away 317 00:27:10,650 --> 00:27:16,210 some packets and the other device does not expect me to throw away packets, then the 318 00:27:16,210 --> 00:27:23,130 Bluetooth stack of a device which now tries to connect to me is going to crash. 319 00:27:23,130 --> 00:27:26,730 So I had the next bug! So I tried to fix one bug. I get the next bug, you know 320 00:27:26,730 --> 00:27:34,650 this. So I actually cannot release any fix, because ... uh. Yeah. Because all of 321 00:27:34,650 --> 00:27:43,710 them still cause the next bug and so on. So how long will this bug be around? 322 00:27:43,710 --> 00:27:47,900 Pretty long probably because there is some devices which are no longer getting vendor 323 00:27:47,900 --> 00:27:53,000 updates. It needs to be in the vendor update, it needs to be this special .hcd- 324 00:27:53,000 --> 00:27:59,960 file. And so on. I mean we can also publish .hcd-files if needed. That's 325 00:27:59,960 --> 00:28:04,100 possible with our framework. That's the good news, but it will probably never be an 326 00:28:04,100 --> 00:28:09,070 official update. And the vendor updates will obviously leak the vulnerability. So 327 00:28:09,070 --> 00:28:15,790 it's chicken-egg. As we found this bug still to be present in devices that were 328 00:28:15,790 --> 00:28:21,610 produced in 2016, we recommend you to turn off Bluetooth - especially if you have a 329 00:28:21,610 --> 00:28:29,430 Broadcom chipset produced before 2017. But in general just turn it off. That's 330 00:28:29,430 --> 00:28:34,720 probably the safest option. And we found out that very old devices having something 331 00:28:34,720 --> 00:28:40,420 like Bluetooth 3.0 are not vulnerable, because that feature that we used didn't 332 00:28:40,420 --> 00:28:46,744 exist back then. But still it's a large number of devices having this issue. 333 00:28:48,796 --> 00:28:50,680 So, thanks for listening. 334 00:28:50,682 --> 00:29:02,660 *Long Applause* 335 00:29:03,140 --> 00:29:09,270 Herald: And again if you have questions we have 8 microphones in the hall. Please 336 00:29:09,270 --> 00:29:12,767 line up at the microphones and you can ask your questions. 337 00:29:15,539 --> 00:29:18,608 The Signal Angel has the first question from the Internet. 338 00:29:18,637 --> 00:29:22,973 Signal Angel: Yes some of the Internet asked if you can guess the Bluetooth MAC 339 00:29:22,990 --> 00:29:30,500 address from the wifi MAC address of a device. Jiska: Yes. So if I go into... Can we 340 00:29:30,500 --> 00:29:38,800 switch the camera on again? On my magic box here. Is that possible? Yes. So 341 00:29:38,800 --> 00:29:49,840 actually, if you go to the "Settings", "About", and then you will see that the 342 00:29:49,840 --> 00:29:53,130 WiFi and Bluetooth MAC address, they are just off by one. 343 00:29:53,130 --> 00:30:02,260 *Laughter and applause* Dennis: So yeah. You have to note however 344 00:30:02,260 --> 00:30:06,640 that this is not the case with every phone. So usually I think new phones 345 00:30:06,640 --> 00:30:13,090 actually try to randomize their Wi-Fi MAC address to be not traceable anymore. Not 346 00:30:13,090 --> 00:30:18,670 sure which devices do that. I think the Nexus 6P does that so the first part will 347 00:30:18,670 --> 00:30:24,040 be the same, because it specifies which vendor this chip was made from. But then, 348 00:30:24,040 --> 00:30:28,590 the lower and least significant bits will change. So it's sometimes possible, 349 00:30:28,590 --> 00:30:32,890 sometimes not. Yeah. I think that's the answer to this question. 350 00:30:32,890 --> 00:30:38,300 Herald: OK. The next question was from the microphone 8 at the very end of the hall. 351 00:30:38,726 --> 00:30:41,929 Eight: Hello. Thanks for your talk. I was 352 00:30:41,929 --> 00:30:47,160 wondering in your second demo, you showed us how you connect to a device, just using 353 00:30:47,160 --> 00:30:53,320 the MAC address and this device was not advertising his name. How do you find a 354 00:30:53,320 --> 00:30:58,640 MAC address, if it's not advertising? Dennis: Yeah. So there are ways to find 355 00:30:58,640 --> 00:31:04,750 out the MAC address of devices which are nearby you. So for example if your device 356 00:31:04,750 --> 00:31:07,880 has Bluetooth turned on but it's not discoverable at the moment, but you're 357 00:31:07,880 --> 00:31:12,060 listening to music on your headphones or if you have a smartwatch connected or 358 00:31:12,060 --> 00:31:16,290 any other Bluetooth device connected, then you will certainly send Bluetooth traffic 359 00:31:16,290 --> 00:31:19,940 and you can sniff that from the air. For example with a software-defined radio or 360 00:31:19,940 --> 00:31:26,310 an Ubertooth. And so in the talk we mentioned and we also have a link to this 361 00:31:26,310 --> 00:31:30,420 in the slide, I guess it was here, "Bluetooth smells like chicken". Michael 362 00:31:30,420 --> 00:31:35,460 Ossman and Dominic Spill, they actually explained very detailed how you can then 363 00:31:35,460 --> 00:31:40,290 infer the MAC address from those packets you sniffed. And, yeah, it's doable. It's 364 00:31:40,290 --> 00:31:42,940 not as easy as with Wi-Fi but it's certainly possible. 365 00:31:42,940 --> 00:31:45,900 Eight: Thank you. Herald: Okay. The next question was at 366 00:31:45,900 --> 00:31:50,360 Microphone number one. One: Thanks for your talk and demos. The 367 00:31:50,360 --> 00:31:59,580 question is, does this firmware have any mitigations against exploitation? And if 368 00:31:59,580 --> 00:32:03,000 we imagine that it has, would it help against such bugs? 369 00:32:03,000 --> 00:32:10,630 Dennis: So. There's no, like real address randomization, kind of the obvious way, 370 00:32:10,630 --> 00:32:14,930 because there's... Most of the things are actually global offsets inside the 371 00:32:14,930 --> 00:32:18,130 firmware. So everything is at fixed addresses, like you would use global 372 00:32:18,130 --> 00:32:25,180 variables all over. There's also the RAM, it's actually executable, so you can 373 00:32:25,180 --> 00:32:29,120 execute on the stack, you can execute on the heap, everywhere. So there's no real 374 00:32:29,120 --> 00:32:34,550 mitigations for such a exploitation. It's like, I don't think even the newer ones 375 00:32:34,550 --> 00:32:36,840 have that sort of, and the Nexus 5 obviously. 376 00:32:36,840 --> 00:32:41,800 Jiska: And another thing that really helps us. So LMP has a version_request, 377 00:32:41,800 --> 00:32:46,580 version_response, which is always sent. So I can ask a device actually: Do you have a 378 00:32:46,580 --> 00:32:51,560 vulnerable firmware and which version? And then I can run exactly the exploit. And 379 00:32:51,560 --> 00:32:55,550 the firmware, I mean, the firmware is standard and I can just run the addresses 380 00:32:55,550 --> 00:33:01,470 that I know for a certain firmware. Herald: Okay. The next question was at 381 00:33:01,470 --> 00:33:05,630 microphone number two. Then again number one, three and five. 382 00:33:05,630 --> 00:33:10,680 Two: Hi. Thanks for the work especially for BT-B-g0ne since like it's the TV-B- 383 00:33:10,680 --> 00:33:17,270 Gone. And I'm not sure of which kind of iPhone that works, because you had a slide 384 00:33:17,270 --> 00:33:22,230 about iPhone up until 6, and then you had a slide that saying if the chip is older 385 00:33:22,230 --> 00:33:26,480 than 2017. So does that work with the last phones as well? 386 00:33:26,480 --> 00:33:30,160 Jiska: Only up to iPhone 6 that was used was the latest I could get. So if you have 387 00:33:30,160 --> 00:33:34,180 an iPhone 8 or something, our attack does not work. 388 00:33:34,180 --> 00:33:38,580 Two: So you're going to work on it? Because a lot of people are playing very 389 00:33:38,580 --> 00:33:42,460 bad music and have new phones. *Laughter* 390 00:33:42,460 --> 00:33:48,070 Jiska: You mean the attack. The attack is not working on iPhone 6, but the general 391 00:33:48,070 --> 00:33:53,340 framework like patching .hcd-files or changing the firmware will obviously work 392 00:33:53,340 --> 00:33:55,910 on any Broadcom chip. Two: Okay, thanks. 393 00:33:55,910 --> 00:33:58,980 Dennis: Broadcom actually uses this mechanism for all their chips, all their 394 00:33:58,980 --> 00:34:03,861 Bluetooth chips, so you can use this framework for every Broadcom chip, every 395 00:34:03,861 --> 00:34:07,650 device that has a Broadcom chip. You only need to do the reverse engineering, as to 396 00:34:07,650 --> 00:34:12,168 get like the real addresses and offsets inside the firmware to do meaningful 397 00:34:12,168 --> 00:34:14,489 patches. Jiska: But for this you always need to be, 398 00:34:14,489 --> 00:34:18,659 to have a rooted device. You need root access on the device to run our patching 399 00:34:18,659 --> 00:34:20,819 framework. Two: Okay. Thanks. 400 00:34:20,819 --> 00:34:23,659 Herald: Okay. Now the question at microphone number one. 401 00:34:23,659 --> 00:34:28,418 One: Do you have a list of vulnerable chipsets? So I can check if my phone is 402 00:34:28,418 --> 00:34:31,819 vulnerable if it's not like in those slides. 403 00:34:31,819 --> 00:34:36,619 Jiska: Yeah, but it's very incomplete. So I also have that, the version numbers and 404 00:34:36,619 --> 00:34:42,309 subversion numbers of those phones. But just consider the time range. So if your 405 00:34:42,309 --> 00:34:47,739 smartphone does Bluetooth 4.0 to 4.2 and it has a Broadcom chip then it's very 406 00:34:47,739 --> 00:34:52,789 likely to be vulnerable. Herald: Okay, now the question from 407 00:34:52,789 --> 00:34:58,750 microphone number three. Three: Thank you for the codes and the 408 00:34:58,750 --> 00:35:06,220 talk. Quick question, so have you looked at a car Bluetooth? And if not, are you 409 00:35:06,220 --> 00:35:12,639 thinking about it? Dennis: So I actually used this tool. As I 410 00:35:12,639 --> 00:35:17,520 mentioned previously, we are also able to test other vulnerabilities, for example 411 00:35:17,520 --> 00:35:23,349 this fixed coordinate invalid curve attack. And so I used my tool to actually 412 00:35:23,349 --> 00:35:27,359 check if a car radio was vulnerable to this fixed coordinate invalid curve attack 413 00:35:27,359 --> 00:35:31,440 that was released this summer. So it's basically patched since half a year but 414 00:35:31,440 --> 00:35:37,030 the car was still vulnerable to this. So the framework is basically usable to test 415 00:35:37,030 --> 00:35:41,440 car radios as well, but I haven't like specifically looked into a car radio. 416 00:35:41,440 --> 00:35:45,130 Three: Thank you. Herald: Okay. Now a question from 417 00:35:45,130 --> 00:35:49,230 Microphone number five. Then we take a question from the Internet and microphone 418 00:35:49,230 --> 00:35:55,990 number six. Five: What is the attack surface exposed 419 00:35:55,990 --> 00:36:02,779 by your exploits? What's the worst case? Could you manipulate memory or something? 420 00:36:02,779 --> 00:36:07,270 Jiska: Worst case it's hard to estimate. I mean we can change some memory addresses 421 00:36:07,270 --> 00:36:12,190 at least in the Nexus 5. And for each smartphone there are other functions by 422 00:36:12,190 --> 00:36:16,770 the compiler put there. So to really know what is happening, we would now need to 423 00:36:16,770 --> 00:36:22,890 analyze like really tons of firmwares and check what is in there and do some 424 00:36:22,890 --> 00:36:28,749 fuzzing. We already found out that some things only happen if you combine multiple 425 00:36:28,749 --> 00:36:32,320 packets and so on. So it's really hard to estimate what is the worst case. So the 426 00:36:32,320 --> 00:36:36,920 very worst case would be, so to say, that you can run arbitrary code in the 427 00:36:36,920 --> 00:36:43,430 Bluetooth, in the Bluetooth firmware itself, and then the next worst case would 428 00:36:43,430 --> 00:36:47,660 be if there would be another vulnerability in the driver, that you could escape 429 00:36:47,660 --> 00:36:52,660 the firmware. So that would be the next step. But that really requires an exploit 430 00:36:52,660 --> 00:36:58,369 chain. So the very worst case would be something similar. So there has been 431 00:36:58,369 --> 00:37:03,970 vulnerabilities in the Wi-Fi part of Broadcom chips where you had the 432 00:37:03,970 --> 00:37:11,540 possibility to really run an exploit chain which then rooted a device in the end. But 433 00:37:11,540 --> 00:37:14,880 it's hard to estimate if you can do it with this or not. 434 00:37:14,880 --> 00:37:18,280 Herald: OK. Now the question from the Internet please. 435 00:37:18,280 --> 00:37:22,940 Internet: Do you know if any older but still supported devices like old MacBooks 436 00:37:22,940 --> 00:37:28,759 are patched and can you actually detect this in any way other than a chip crash? 437 00:37:28,759 --> 00:37:38,100 Jiska: Not really, so we can try to not crash the chip by first checking if it is 438 00:37:38,100 --> 00:37:42,810 sending appropriate answers, but typically the really only thing to be sure is that 439 00:37:42,810 --> 00:37:48,260 it crashes. So that so far is the only way, because I mean obviously, if Broadcom 440 00:37:48,260 --> 00:37:52,020 would tell "the following chips are vulnerable", which they didn't so far, 441 00:37:52,020 --> 00:37:57,430 because that's also to protect themselves probably, then you could be sure. But yeah 442 00:37:57,430 --> 00:38:01,979 as of now that's the only way to check it. Herald: Thank you. Now the question from 443 00:38:01,979 --> 00:38:06,200 microphone number six please. Six: Yeah. Would it be possible to 444 00:38:06,200 --> 00:38:13,120 increase the Bluetooth radio transmission power by patching the firmware? So that 445 00:38:13,120 --> 00:38:18,209 Bluetooth works across entire buildings and not only in a single room? 446 00:38:18,209 --> 00:38:23,030 Dennis: Yeah. So the thing is, we are actually now patching the firmware of the 447 00:38:23,030 --> 00:38:27,069 chip, and the firmware does like all the the link layer stuff of Bluetooth. The 448 00:38:27,069 --> 00:38:31,480 real physical part is probably done in another component inside the chip which 449 00:38:31,480 --> 00:38:36,210 may be running another kind of small real- time firmware and we haven't found that 450 00:38:36,210 --> 00:38:40,079 yet. We are still looking for it because that must be in there somewhere, like that 451 00:38:40,079 --> 00:38:44,529 Bluetooth modem and maybe we can actually change the settings for this modem. I 452 00:38:44,529 --> 00:38:48,760 don't think it will be too drastical. But maybe if you're in different areas of the 453 00:38:48,760 --> 00:38:52,049 world and like your Bluetooth has different strengths in different areas of 454 00:38:52,049 --> 00:38:56,010 the world, you can maybe manipulate that. But we haven't found it yet. 455 00:38:56,010 --> 00:38:59,090 Six: OK. Thank you. Herald: Okay. Next question is coming from 456 00:38:59,090 --> 00:39:03,730 microphone number four. Four: Does the Bluetooth chipset have 457 00:39:03,730 --> 00:39:08,599 access to system RAM? Dennis: Sorry I didn't get the last word. 458 00:39:08,599 --> 00:39:09,923 Jiska: The system rights or what do you mean? 459 00:39:09,923 --> 00:39:13,770 Four: The system RAM, memory. Dennis: You mean the memory of the main 460 00:39:13,770 --> 00:39:16,499 processor like where Android or iOS is running on? 461 00:39:16,499 --> 00:39:19,589 Four: Yes. Dennis: No it's not like as with Wi-Fi 462 00:39:19,589 --> 00:39:23,940 where you have direct memory access. But Bluetooth, the HCI interface is the only 463 00:39:23,940 --> 00:39:29,569 interface between those two processors. And this is usually done over either USB 464 00:39:29,569 --> 00:39:36,329 or in the Nexus 5 is actually UART. Herald: Next question is coming from 465 00:39:36,329 --> 00:39:39,930 microphone number three. Three: Many thanks for the enlightening 466 00:39:39,930 --> 00:39:43,750 and scary talk. I missed a little bit of the beginning maybe that question was 467 00:39:43,750 --> 00:39:50,970 inside there. Did you or do you considered to disclose this vulnerability for example 468 00:39:50,970 --> 00:39:56,369 to BSI (Bundesamt für Sicherheit in der Informationstechnik)? As I would consider 469 00:39:56,369 --> 00:40:01,930 their obligation to inform general public like put a note on their website saying: 470 00:40:01,930 --> 00:40:06,900 "Look, if you're running a certain smartphone you're vulnerable to a certain 471 00:40:06,900 --> 00:40:11,810 attack!" And that would put much more stress on the vendors to really look into 472 00:40:11,810 --> 00:40:14,124 this. Jiska: Yeah that sounds like a good 473 00:40:14,124 --> 00:40:22,480 option. So far we're, so we asked Broadcom when we can publish things and at least 474 00:40:22,480 --> 00:40:26,690 they agreed that it's no problem to publish it in summer, then it would be 475 00:40:26,690 --> 00:40:31,029 public for everyone. But yeah, BSI would also be a nice option. 476 00:40:31,939 --> 00:40:33,589 Three: Thank you. 477 00:40:33,589 --> 00:40:36,440 Herald: OK. Is there another question from the Internet? 478 00:40:37,024 --> 00:40:38,624 … 479 00:40:40,409 --> 00:40:45,699 Please switch on the microphone for the Internet. 480 00:40:45,699 --> 00:40:50,829 Internet: Hello? Hi. So do you know if any devices have been patched yet, which have 481 00:40:50,829 --> 00:40:55,229 not been released after 2017, or are there no rolled out patches? 482 00:40:55,229 --> 00:41:01,430 Jiska: I don't think so. So, it took Broadcom two months to actually confirm 483 00:41:01,430 --> 00:41:05,700 that there is this vulnerability. So on December 3rd they said, ooops it really 484 00:41:05,700 --> 00:41:12,279 exists. And then on December 9th, they were like: "Ooh, do you really plan to do 485 00:41:12,279 --> 00:41:15,430 that talk here?!" *Laughter* 486 00:41:15,430 --> 00:41:22,430 And I did the most recent iOS update on the iPhone 6 that I just showed you. And 487 00:41:22,430 --> 00:41:26,490 this one is still valuable. I think it takes some time for testing. So I would 488 00:41:26,490 --> 00:41:32,309 say the first patches will come out maybe in 1, 2 months, but we don't know. 489 00:41:32,309 --> 00:41:35,670 Herald: Okay. One last quick question from microphone number one. 490 00:41:35,670 --> 00:41:40,180 One: So is it … do you think it is possible to trace back when was this 491 00:41:40,180 --> 00:41:44,900 vulnerability introduced, so we can go back and try to hack old devices that 492 00:41:44,900 --> 00:41:49,670 probably have the same firmware or firmware vulnerability? Because they 493 00:41:49,670 --> 00:41:55,539 should be backward compatible, right? So if the same handler is implemented I 494 00:41:55,539 --> 00:42:00,130 know in 2012 first and for the first time then uh... 495 00:42:00,130 --> 00:42:02,510 Jiska: Yeah. One: Probably the devices can be narrowed 496 00:42:02,520 --> 00:42:04,829 down, right? Jiska: So at least.. so the Nexus 5 has a 497 00:42:04,829 --> 00:42:14,990 firmware from 2012 actually. So somewhere, so the June 2nd is when it still existed 498 00:42:14,990 --> 00:42:21,220 in 2014. I don't know. So in each firmware there is a build date and I would then 499 00:42:21,220 --> 00:42:25,559 need to extract the firmware of vulnerable devices and so on, so it's a long process, 500 00:42:25,559 --> 00:42:28,690 but at least the vulnerability was there for multiple years. 501 00:42:30,070 --> 00:42:34,530 Herald: Okay now give please a huge round of applause for Jiska Classen 502 00:42:34,530 --> 00:42:36,540 and Dennis Mantz for their talk. 503 00:42:36,540 --> 00:42:37,310 *Applause* 504 00:42:37,310 --> 00:42:39,291 Dennis: Thank you! *Applause* 505 00:42:39,291 --> 00:42:45,166 *35C3 outro music* 506 00:42:45,166 --> 00:43:03,000 subtitles created by c3subtitles.de in the year 2019. Join, and help us!