WEBVTT 00:02.140 --> 00:07.520 Hello everyone and welcome to the talk Spectra, which is about new wireless escalation targets. 00:07.620 --> 00:15.620 This is a joint work by me, Jeska and Francesco, who has been working a lot with Wi-Fi while I have been working with Bluetooth in the past. 00:15.620 --> 00:20.240 And in this work, we join our abilities to build a new attack scheme. 00:21.240 --> 00:24.760 So the motivation of this is as simple as this. 00:24.760 --> 00:28.760 I found a partial Bluetooth RCE a while ago. 00:28.760 --> 00:34.320 And then a bit later, a student of mine, Jan, built a fuzzer Frankenstein, which emulates the Bluetooth chips. 00:34.320 --> 00:38.540 And he also found a couple of more remote code executions. 00:38.820 --> 00:42.080 And with this, I said like, yeah, that's a great chance. 00:42.080 --> 00:50.620 Now we can tour the world, tell everyone like we have Bluetooth remote code execution, take my unicorn, travel with it, and just show everyone. 00:50.840 --> 01:01.500 But the thing is that people said they are not too surprised about Bluetooth remote code execution because, you know, Bluetooth after 22 years is really indistinguishable from magic. 01:01.580 --> 01:04.220 And they kind of expected that it is broken. 01:05.960 --> 01:10.900 And then people also told me, you know, there is Bluetooth RCE, there's Wi-Fi RCE. 01:10.900 --> 01:18.940 And Wi-Fi RCE is much cooler because, first of all, Bluetooth, it's connected via UART, and Wi-Fi is connected with PCI Express. 01:18.940 --> 01:21.840 That is just nicer for exploitation. 01:21.840 --> 01:26.680 And also, if you can pop KALC, it's a nice attack. 01:26.680 --> 01:32.680 But if you cannot pop KALC, then what kind of attack is a Bluetooth on-chip remote code execution? 01:33.880 --> 01:43.840 So I was thinking, because now the idea is, of course, like I could try to like take the Bluetooth RCE and then break into the operating system all the way up. 01:43.840 --> 01:50.300 But another funny attack would be to instead attack the Wi-Fi chip or maybe even the LTE chip. 01:50.300 --> 01:57.040 So to break the interchip separation instead of doing the same thing again of breaking into the operating system. 01:58.560 --> 02:04.300 And then I called Francesco and said like, hey, let's build speculative transmission. 02:04.640 --> 02:14.980 And the idea of the attack was that in a smartphone, you have the same frequency used by Wi-Fi and Bluetooth and LTE has harmonics in the same spectrum. 02:14.980 --> 02:19.120 And they cause interference and in such a small device. 02:19.120 --> 02:25.960 So they need to arbitrate the channel access, which means they need to actually tell I'm sending a packet. 02:25.960 --> 02:31.040 Can you please not send a packet right now and so on and also need to tell priorities and so on. 02:31.040 --> 02:36.160 And this is called a coexistence mechanism, and it's a performance optimization. 02:36.400 --> 02:44.840 And of course, you could now also instead speculatively transmit a packet and use this to infer what the other cores are doing. 02:44.840 --> 02:47.060 So this was the initial attack idea. 02:47.060 --> 02:53.380 In the end, it turned out to be a bit more of a spectrum transmission, but this is the attack scheme. 02:53.640 --> 02:57.880 Of course, it requires a lot of expectation before. 02:57.880 --> 03:04.420 So it requires the Bluetooth remote code execution or Wi-Fi remote code execution to then escalate into the other chip. 03:04.420 --> 03:11.900 But the interesting part here is, as this is a connection directly between the chips, you cannot block it with the operating system. 03:11.900 --> 03:16.420 So there is a very nice attack vector that is hard to prevent. 03:17.800 --> 03:22.200 And if you look into a modern iPhone, this is what it roughly looks like. 03:22.200 --> 03:30.040 So you have the Bluetooth and the Wi-Fi chip, which are within a combo chip, but they still run on different ARM cores. 03:30.160 --> 03:33.600 And they are connected via the serial enhanced coexistence interface. 03:33.600 --> 03:35.420 This is what we are going to attack. 03:36.140 --> 03:43.820 The combo chip is also interconnected with an LTE chip, and this is using mobile wireless standards. 03:44.260 --> 03:48.940 And then you can also see that the Bluetooth daemon has fewer writes than the Wi-Fi daemon. 03:48.940 --> 03:55.060 And the Bluetooth chip is usually connected with UI, the newer iPhones use PCI Express here. 03:55.060 --> 04:00.580 And now, if you could escalate between the chips, you have new attack paths that become possible. 04:00.580 --> 04:08.640 So for example, I could now start from Bluetooth over the air and then escalate into Wi-Fi and then go all the way up. 04:08.640 --> 04:13.500 Or I could also try to infer timings in between those chips and so on. 04:15.460 --> 04:21.360 The spectral impact can be very different depending on how this coexistence interface is implemented. 04:21.360 --> 04:27.580 So first of all, the most obvious one is the denial of service, if one core denies transmission to another core. 04:27.580 --> 04:32.940 But it could also be information disclosure via timings or packet types and so on. 04:33.020 --> 04:35.620 And the worst case would be code execution. 04:35.620 --> 04:38.840 And for this one, you really need to screw up your implementation. 04:39.680 --> 04:46.320 When this attack has been first on the internet because of the blackhead abstract, someone started tweeting and giving it other names. 04:46.320 --> 04:52.120 And I have to say, I also like the queer ghost attack, but spectra is like the original name. 04:52.120 --> 04:58.420 Of course, it's harder to find this on the internet because spectra is just a very generic word. 05:00.860 --> 05:06.440 And now let's go for the Broadcom coexistence interface, which we are now going to exploit. 05:06.600 --> 05:13.280 This is also present in a couple of Cypress chips because Cypress acquired parts of Broadcom in 2016. 05:13.520 --> 05:16.400 So it's synonymous to be used here. 05:16.400 --> 05:21.040 So don't be confused if I mix up Broadcom and Cypress, it's all the same. 05:22.520 --> 05:27.300 Actually, Broadcom is a very nice target because they don't do any firmware checks. 05:27.300 --> 05:37.960 And no firmware checks means that if we are able to reverse engineer certain parts of the firmware, then we can also patch it within Wi-Fi and within Bluetooth. 05:38.080 --> 05:44.340 And there are no further checks, which means that there is no secure boot, no signature checking, etc. 05:44.340 --> 05:54.100 So you still need to understand what is going on to patch such a chip, but then there are no further security measures to prevent this. 05:54.340 --> 05:57.180 And those chips are in many, many, many devices. 05:57.180 --> 06:09.120 So for example, all iPhones, MacBooks, iMacs and also the older Apple Watches, the newest ones have a different one, the Samsung Galaxy S series, the older Google Nexus phones or Raspberry Pis, a couple of IoT devices and so on. 06:09.120 --> 06:14.060 So this is a very nice prototyping platform for all kinds of attacks. 06:16.280 --> 06:24.060 If you look into the older data sheets, you can also find a couple of details, still not everything, but the newer data sheets just don't exist. 06:24.060 --> 06:27.140 So we need to live with what is there, what is documented. 06:27.160 --> 06:36.380 And what you can see here, there's this Bluetooth chip, there is a Wi-Fi chip, they share an antenna, so they need to arbitrate access onto this one. 06:36.440 --> 06:42.460 And then there is a lot of stuff going on between those chips, which we are going to attack in the following. 06:42.700 --> 06:44.600 Nonetheless, they have different ARM cores. 06:44.600 --> 06:48.820 So this one has an ARM Cortex-M3, there's the Cortex-R4 and so on. 06:48.820 --> 06:51.980 So this is still separated in some ways. 06:55.170 --> 07:03.210 For understanding the attacks now, we need to understand the Serial Enhanced Coexistence Interface, which is used between Wi-Fi and Bluetooth. 07:03.210 --> 07:13.810 It's also called ECI, so without the serial, and GCI, which might be Global or Generic Coexistence Interface, but it's all used in the same way in the data sheets. 07:15.070 --> 07:20.690 To understand it, the best way is to actually separate Bluetooth and Wi-Fi. 07:20.690 --> 07:25.250 And in this setup, you can see that there is a Bluetooth and a Wi-Fi board by Cypress. 07:25.310 --> 07:36.350 They don't have a shared antenna, so everything is separate, there are no side effects, and the only connection that they have is the Serial Enhanced Coexistence Interface, which we can now also intercept. 07:36.530 --> 07:48.590 So that means that we are actually able to observe each and every signal that is sent between those two boards, and there is nothing else that is going on that could block a transmission. 07:50.830 --> 08:01.130 If you look into this in detail, first of all we did the experiments of streaming just some music over Bluetooth, and then on the Wi-Fi chip we did a scan for other Wi-Fis. 08:01.130 --> 08:11.190 You can see a peak when you start the scan, actually it's two peaks, and then there are a couple of other peaks when you get the scan results, and the end of the scan. 08:11.190 --> 08:28.210 And what is very interesting about this protocol already at this level is that the Bluetooth and Wi-Fi are sending with three megabytes over the Serial Interface, and three megabytes is also the same amount of data that is sent from the Bluetooth chip to the host to send the actual music of the stream. 08:28.210 --> 08:33.370 So you can imagine how much data there is within the Coexistence Interface. 08:34.250 --> 08:44.390 And now you can see that Bluetooth is within each peak actually sending some data that is annotated in hex here, and also Wi-Fi is sending some data. 08:44.390 --> 08:52.410 So each tiny peak there really has some information about the task that is running and other stuff that tells priorities of packets. 08:53.050 --> 09:01.910 And in the last example you can also see a Bluetooth keyboard which has regular peaks that is then being sent while Wi-Fi is idle. 09:01.910 --> 09:07.030 So this is roughly what it looks like just to give you some idea about this protocol. 09:09.380 --> 09:14.880 In the first attack we didn't even need to understand all the details of this. 09:14.880 --> 09:18.860 It's just a simple reconfiguration of this interface. 09:18.920 --> 09:28.380 So there are a lot, a lot, a lot of registers that are mapped into the Bluetooth ARM core that you can write into or read from. 09:28.380 --> 09:37.520 And actually I tried to understand all of them in the very beginning, and you can also do fancy stuff with this, but I didn't understand all of them. 09:37.520 --> 09:42.100 And then Francesco just told me, well if you don't understand it, just try breaking it. 09:42.100 --> 09:45.540 Just write something in all those registers and see what breaks. 09:45.940 --> 09:51.940 And I found out when I write just apps into the GCI chip control, this crashes Wi-Fi. 09:51.940 --> 09:57.780 And more interestingly in this evaluation board setup I could even see some voltage drop on the logic analyzer. 09:57.780 --> 09:59.540 This was very weird. 09:59.700 --> 10:12.400 And on some devices this even causes a kernel panic, because upon writing to the GCI chip control within Bluetooth, Wi-Fi might stop or even spam stuff over PCI Express and so on. 10:12.400 --> 10:15.780 And then there are very weird effects from this. 10:16.620 --> 10:28.220 I tested it on a couple of devices, so starting from the Nexus 5, but then also going all the way up to the newest MacBooks and iPhones and so on, and the Samsung Galaxy S10, S20. 10:28.220 --> 10:38.640 And what you can see here is that first of all, depending on the date of the chip you have a slightly different scheme, but on the newest ones you just write apps into one address. 10:38.900 --> 10:43.640 And already this is sufficient to have a kernel panic on a lot of those devices. 10:43.640 --> 10:47.460 On some of them it's also just Wi-Fi that restarts and that's it. 10:48.620 --> 10:56.520 Now this already looks very promising for such a simple attack, and because of this we tried to build more fancy attacks with this primitive. 10:56.780 --> 11:00.040 And this is what Francesco is now going to tell you about. 11:04.890 --> 11:08.010 Thanks Gisca for introducing this part of the talk. 11:08.010 --> 11:11.030 Let's start describing the Broadcom Wi-Fi chipset. 11:11.030 --> 11:22.490 In the last two decades it evolved from a soft Mac to a full Mac implementation, and functions that were originally running on the Linux host at the top are today offloaded by an intermediate ARM core. 11:22.490 --> 11:29.690 Interestingly, low-level operations are always managed by the same piece of hardware that did not change much in 70 years. 11:29.690 --> 11:40.350 No matter which Wi-Fi chipset we are using, critical operations are managed by the same D11 microcontroller that coordinates PHY, radiofrequency and VMA operations. 11:40.350 --> 11:42.790 Let's have a closer look to the low-level. 11:42.790 --> 11:51.530 The D11 microcontroller runs the microcode, a short piece of software that keeps checking hardware conditions and triggers specific operations. 11:51.530 --> 12:00.110 We see here some code from the main loop that checks if the PHY started receiving a PLCP preamble, or if the current reception is terminated. 12:00.110 --> 12:05.850 In such cases it will execute the corresponding handlers that will decide what to do with the current PHY. 12:05.850 --> 12:11.410 This other piece of code is extracted from the part that schedules the transmission of an acknowledgement. 12:11.410 --> 12:15.870 We see the preparation of the reply frame that starts with D4 as usual. 12:15.870 --> 12:20.410 The D11 toolchain was created by Michael Buech in 2007. 12:20.410 --> 12:28.510 We incorporated it inside our Netman project and we periodically update it by adding new instructions when a new chipset is introduced. 12:28.510 --> 12:36.250 As spotting the new code in the ARM binary blob is easy, we can modify it adding customized parts, as we will see later. 12:36.250 --> 12:39.130 The D11 CPU coordinates many blocks. 12:39.130 --> 12:49.850 First of all, it controls the transmission and reception engines, it manages channels access by scheduling transmissions, and the sides which received frames should be pushed to the ARM core. 12:49.850 --> 12:58.990 It can configure the PHY and the radio, and it does so by running the U-code that is loaded into the U-code memory by the ARM firmware during initialization. 12:58.990 --> 13:14.470 The D11 has access to an 8 kilobyte shared memory where it keeps its configuration and state variables, and it also accesses indirectly the ARM memory where packets ready for transmissions are queued for deciding which packets can be transmitted or aggregated. 13:14.470 --> 13:23.350 The D11 is equipped with general purpose timers and with many different interfaces for talking to other parts of the chipset, like the Secchi interface. 13:23.350 --> 13:33.870 During the years it turned out to be a pretty flexible architecture and we used it as a research platform for showcasing operations like jamming, piggybacking schemes, and time-of-flight measurements. 13:33.870 --> 13:37.370 Let's now talk about the D11 coexistence interface. 13:37.370 --> 13:43.050 It includes quite a number of registers and a 64-bit buffer for receiving messages from the Bluetooth. 13:43.050 --> 13:50.030 Such messages are transmitted by Bluetooth every 1.25 milliseconds, that is the minimum Bluetooth connection interval. 13:50.030 --> 13:54.710 They report to Wi-Fi the timing and type of all Bluetooth operations. 13:54.710 --> 14:03.350 Wi-Fi copies this information inside dedicated Secchi countdown timers that defer Wi-Fi operations and prevent collisions. 14:03.350 --> 14:11.290 On the opposite direction, Wi-Fi uses the Bluetooth transmission control register, in red, for granting Bluetooth access to the chip. 14:11.290 --> 14:16.210 The flow of messages in the two directions builds a grant-reject scheme. 14:16.210 --> 14:22.430 As we will see, in our attacks we used the knowledge we collected on such registers for breaking such scheme. 14:22.430 --> 14:28.210 According to our analysis, more than 10% of the U-code is dedicated to coexistence. 14:28.210 --> 14:35.750 As in general many other operations take much less code, we understand how much complex is the coexistence interface. 14:35.750 --> 14:46.830 Finally, by programming two boards for transmitting Secchi messages when receiving the same Wi-Fi beacon, we measured, with the help of an external FPGA, the jitter of the Secchi line. 14:46.830 --> 14:52.410 It turned out to be Gaussian with 200 nanosecond deviation, which is perfect for this application. 14:52.410 --> 14:55.570 So let's see how we broke the grant-reject scheme. 14:55.570 --> 15:04.850 We did that to see the effects when watching a movie that requires to download content over the Wi-Fi and send audio to a Bluetooth headset. 15:04.850 --> 15:09.810 At the bottom, in green, we see Secchi grant messages transmitted by the Wi-Fi. 15:09.810 --> 15:14.590 Bluetooth uses them for understanding when it can transmit audio to the headset. 15:14.590 --> 15:21.410 We introduce it into the U-code a few lines for configuring the Wi-Fi chipset remotely from the air interface. 15:21.410 --> 15:26.590 We can hence prevent the Wi-Fi from sending Secchi grant messages to Bluetooth. 15:26.590 --> 15:30.830 You see this happens between 2.6 and 3.5 seconds. 15:30.830 --> 15:37.410 During this interval no more Secchi messages are transmitted and, in fact, we cannot hear any sound from the headset. 15:37.410 --> 15:42.290 We tested this both on a Nexus 5 and on development boards from Cypress. 15:42.290 --> 15:49.630 This experiment clearly demonstrates that a denial-of-service attack from the Wi-Fi side against Bluetooth is possible. 15:49.630 --> 15:57.250 Let's take a closer look now at the messages that Bluetooth sends to Wi-Fi and if we can use such information for an attack. 15:57.250 --> 16:02.270 These are the Secchi time diagrams when we have a keyboard connected over Bluetooth. 16:02.270 --> 16:08.710 Depending on the keyboard, we can observe Secchi messages transmitted every 15 or 30 milliseconds. 16:08.710 --> 16:17.410 Bluetooth sends these Secchi messages to inform Wi-Fi that it is going to poll the keyboard so that Wi-Fi defers channel access meanwhile. 16:17.410 --> 16:22.530 In this diagram Wi-Fi is idle, so Wi-Fi always grants access to Bluetooth. 16:22.530 --> 16:26.730 This is what happens when somebody is actually typing on a keyboard. 16:26.730 --> 16:30.330 At the bottom we have the periodic sequence of Secchi messages. 16:30.330 --> 16:36.010 On top we have the key presses sniffed by Wireshark when capturing from the Bluetooth interface. 16:36.010 --> 16:45.070 As we are typing with moderate speed, each key press is separate from the others and we can also see the Bluetooth message with key release following each key press. 16:45.070 --> 16:52.270 In between we can see the HID data captured by Wireshark with a specific event ID that represents a key press. 16:52.270 --> 16:57.890 Below we see Secchi messages that we filtered on the Wi-Fi chipset by selecting the same message type. 16:57.890 --> 17:04.550 This demonstrates that at the Wi-Fi side we can easily distinguish Secchi messages related to key presses. 17:04.550 --> 17:20.450 This clearly demonstrates that having access to the Wi-Fi chipset is enough for measuring key press timings with very accurate resolution and we know that in some cases with the help of some artificial intelligence or classification technique this is enough for guessing what a user is typing. 17:20.450 --> 17:31.810 We hence believe that without any further protection the Secchi interface can be used for mounting side channel attacks and we requested the CVE for reporting the associated vulnerability. 17:31.810 --> 17:34.010 Francesca, the ground is yours again. 17:36.050 --> 17:43.150 Thank you Francesco for the very detailed explanations about the serial enhanced coexistence interface and attacks on it. 17:43.150 --> 17:52.630 There is still one thing mentioned in the data sheet which was clearly missing which is the WLAN RAM sharing and in the following we are also going to attack this. 17:53.290 --> 18:23.570 I would call this effect when you spend too much time looking for very fancy side channels and dig deeper into all of this and try to explore them while there is the one obvious thing in a data sheet that you just couldn't find within the serial enhanced coexistence interface and for us this was this WLAN RAM sharing so it must be somewhere it's in the data sheet errors just go into one direction here from Bluetooth to Wi-Fi and we just didn't understand where it is and couldn't find it for quite a long time. 18:24.610 --> 19:23.550 And the reason for this is that the Cypress boards come with some development kit and within this there are some symbol leaks but the problem here is there's nothing mentioned with WLAN and so there probably is no WLAN RAM sharing I thought maybe it's just another word for the enhanced coexistence mappings but then there was also another part of symbols and I was able to obtain a ROM image and it's not from a development board but actually A little pause... and we are back... 19:23.570 --> 19:31.630 The beginning of the section, I actually saw, wow, there is a string 802.11 something on the device where I did this. 19:31.630 --> 19:34.310 And then I was like, probably I'm already in there. 19:34.350 --> 19:38.350 Still, to confirm it, I instead write writing to it. 19:38.570 --> 19:43.930 And when I write to this, what happens is that quite often the Wi-Fi crashes. 19:43.930 --> 19:48.530 So within Bluetooth, I write into those registers and suddenly Wi-Fi crashes. 19:48.530 --> 19:54.470 And the nice part about a Wi-Fi crash is that on a couple of devices, this is causing a crash dump. 19:54.570 --> 19:59.030 And this crash dump actually contains parts of the RAM image. 19:59.030 --> 20:07.530 So I could write data that I know and try to find the same data again to make the mapping and find like how Wi-Fi and Bluetooth are wrapped into each other. 20:07.820 --> 20:12.570 And also it revealed a couple of pointers, function pointers. 20:12.570 --> 20:16.770 So within the function pointer table, I was just overwriting a couple of pointers. 20:16.770 --> 20:20.450 And it turned out that if in this position, there is a pointer table. 20:20.450 --> 20:23.330 And when I write to this, I can get the program counter under control. 20:23.330 --> 20:26.050 So I can write to RAM, I can set the program counter. 20:26.090 --> 20:28.110 So I can have code execution. 20:28.390 --> 20:30.330 And that was really amazing. 20:30.930 --> 20:33.490 I have a demo video for this on a MacBook. 20:33.550 --> 20:34.950 The mapping is slightly different. 20:34.950 --> 20:43.850 So on the left hand side, I use internal glue to write assembly instructions, because I'm just writing within a function and not within a function pointer. 20:43.850 --> 20:48.070 And then on the right hand side, you see the Wi-Fi crash logs on macOS. 20:48.070 --> 20:51.250 And you can see that I can get a program counter under control. 20:51.490 --> 20:53.850 And this is how fast this attack works. 20:53.850 --> 20:57.130 So just within Bluetooth, I can get code execution in Wi-Fi. 20:59.550 --> 21:04.190 The interesting part here is that I couldn't find this area on the Nexus 5. 21:04.190 --> 21:08.010 So either it's not mapped at all, or it's mapped to a different region. 21:08.010 --> 21:15.590 Even though this was the one that I initially had as the idea, like from this data sheet, there must be this Wi-Fi RAM sharing. 21:15.590 --> 21:17.730 So this one, I didn't find it. 21:17.770 --> 21:25.290 Then there are a couple of devices where within the ROM dump, you can even find the 680000 and so on. 21:25.290 --> 21:28.750 So you know that within the firmware, this is used. 21:28.750 --> 21:31.030 And on those, also the attack works. 21:31.110 --> 21:34.190 The fun part here is that the MacBook, I don't have it with me. 21:34.190 --> 21:35.630 I just have this dump. 21:35.630 --> 21:38.590 So I couldn't try it on my own on this MacBook. 21:38.590 --> 21:42.450 But at least I know it should work because the symbol is there. 21:42.830 --> 21:51.570 And in the newest devices, this register is never ever mentioned in the firmware, but still the attack works. 21:51.570 --> 21:55.750 So it's probably a feature that has been abandoned, and it's no longer used. 21:55.750 --> 21:59.890 But still, we can use it for this type of attack on all those devices. 22:02.620 --> 22:08.380 The even more fun part is that sometimes I got again issues with PCI Express. 22:08.400 --> 22:09.920 So why is that? 22:10.960 --> 22:14.880 On all those chips, I had no idea what exactly I was doing. 22:14.880 --> 22:20.920 So I mean, yes, there is the mapping, but I first of all need to get the chip to crash to get this ROM image. 22:20.920 --> 22:27.920 And then I need to load it into IDA and analyze it and somehow find a place to get code execution for each chip. 22:28.240 --> 22:30.020 And so I was just writing certain things. 22:30.020 --> 22:32.320 And then again, like sometimes finding a pattern again. 22:32.320 --> 22:37.340 And when I find the pattern like in the program counter, then I probably have code execution. 22:37.340 --> 22:40.420 So this was roughly my approach. 22:40.860 --> 22:45.100 And then on a couple of devices, this turned out to be a very efficient puzzle. 22:45.100 --> 22:55.780 So just flipping a couple of bytes somewhere in the shared memory between Wi-Fi and Bluetooth was sufficient to get kernel panics on a couple of devices. 22:56.040 --> 22:59.760 So sometimes just Wi-Fi crashes, but sometimes even kernel panics. 22:59.980 --> 23:10.100 And this is interesting because there are of course also some memory areas that are used for the PCI express queue between the Wi-Fi chip and the host and so on. 23:10.100 --> 23:15.300 Or it might just simply block something within the communication between the Wi-Fi chip and the host. 23:15.300 --> 23:18.780 And depending on this, it can already cause a reboot. 23:18.780 --> 23:27.500 So with the super simple fuzzer of just flipping some bytes or like exchanging some bytes, you can reboot devices. 23:27.500 --> 23:29.800 This is a capture of this. 23:29.920 --> 23:33.240 I just use an iPhone 6 because on this one it's very fast. 23:33.240 --> 23:35.440 It also works on a couple of other devices. 23:35.780 --> 23:38.320 And you can see first of all Wi-Fi is switched off. 23:38.320 --> 23:43.160 So that's on the left hand side and then the device is already rebooting. 23:47.560 --> 23:50.460 Now you might wonder what the patch looks like. 23:50.560 --> 23:54.700 And I mean a lot of this is in hardware, so you cannot really patch it. 23:54.700 --> 24:00.860 But what I have seen in a couple of devices is that they are now blocking the communication. 24:00.860 --> 24:12.660 So after the Bluetooth chip is initialized by the Bluetooth daemon, the Bluetooth chip is then blocking any write RAM, read RAM commands or at least writing. 24:12.660 --> 24:20.400 The reading is only blocked on a few devices, but writing is blocked on all newer chips as far as I've seen. 24:20.400 --> 24:29.700 And now the thing is that this prevents at least attacks where the Bluetooth daemon would try to get code execution within Wi-Fi. 24:29.700 --> 24:31.200 So that's like this path. 24:31.200 --> 24:38.840 But what is not prevented by this is if you have remote code execution over the air and then escalate into Wi-Fi. 24:38.840 --> 24:56.060 Or if you just know that the timing between Wi-Fi and Bluetooth is a fixed one by now and use the known timing, which is not random because of something sent over the air, but actually like predictable because of coexistence schemes, this might also be a thing that's exploitable here. 24:56.140 --> 25:02.500 But at least they added this to the attack model that suddenly Bluetooth might be able to attack Wi-Fi. 25:02.500 --> 25:06.380 And because of this, this part is now blocked because you can block this quite easily. 25:08.800 --> 25:17.240 And now I mentioned in the chips. 25:18.020 --> 25:30.600 If you look into the Bluetooth specification and read it backwards, because I mean I'm a reverse engineer, so I also read the specification backwards obviously, what you can see on the last page is the Bluetooth logo. 25:30.600 --> 25:34.880 And on the second last page, it already starts with the mobile wireless standards. 25:35.900 --> 25:44.840 And this is another serial protocol which is used between Wi-Fi and Bluetooth chips or Bluetooth chips and LTE. 25:45.160 --> 25:50.660 And they are also sending activity information and so on over UART. 25:50.660 --> 25:56.280 And then there is another thing that goes via the operating system to initially configure it. 25:56.280 --> 25:58.560 And this one is also used on iPhones. 25:58.560 --> 26:02.680 So I saw it on an iPhone, so it probably is also attackable on them. 26:03.520 --> 26:12.840 And because everyone has some proprietary coexistence features, we asked Broadcom if we can also include other manufacturers in the response disclosure process. 26:12.840 --> 26:14.700 And they said yes, we can. 26:14.800 --> 26:21.720 And so we informed a couple of those who at least mentioned that they have coexistence in their data sheets and so on. 26:21.720 --> 26:32.740 And some of their responses were like that this doesn't really apply to them because there are some chips that have just one core that handles multiple wireless protocols. 26:32.780 --> 26:40.220 So by definition, that wouldn't be attackable in the sense of you already have code execution either way. 26:40.220 --> 26:44.340 So Bluetooth remote code execution is automatically a Wi-Fi remote code execution. 26:44.540 --> 27:03.440 But of course, there might be other side channels like I can now from the timing of Wi-Fi frames that I sent on an upper layer, maybe predict how the typing on a keyboard or something was, for example, or how the activity was on the other wireless core. 27:03.440 --> 27:12.000 And this might be something that could still be possible even though the code execution is kind of by design and cannot be prevented, there might be further attacks. 27:14.320 --> 27:27.000 And as a summary, so what we reached is if you have a Bluetooth remote code execution on a Broadcom chip, you can now cause driver kernel panics, get information disclosure about Wi-Fi, and even code execution within Wi-Fi. 27:27.000 --> 27:35.140 And the other way around, if you have a Wi-Fi remote code execution, you can now do denial of service against Bluetooth and also get information disclosure within Bluetooth. 27:37.460 --> 27:40.500 If you have further questions, there will be a Q&A session. 27:40.520 --> 27:45.520 And you can, of course, also reach me on Twitter, or you can write an email to Francesco and me. 27:45.740 --> 27:46.840 Thanks for listening.