 Hello everyone and welcome to the Talk Spectra, which is about new wireless escalation targets. This is a joint work by me, Jiska and Francesco, who has been working a lot with Wi-Fi, while I have been working with Bluetooth in the past. And in this work, we join our abilities to build a new attack scheme. So the motivation of this is as simple as this. I found a partial Bluetooth RCE a while ago and then a bit later, a student of Mein Jan built a fuzzle Frankenstein which emulates the Bluetooth chips and he also found a couple of more remote code executions. And with this, I said like, yeah, that's a great chance. Now we can tour the world, tell everyone, like we have Bluetooth remote code execution, take my unicorn, travel with it and show everyone. 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 and they kind of expected that it is broken. And then people also told me, you know, there is Bluetooth RCE, there's Wi-Fi RCE. 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 that it's just nicer for exploitation. And also, if you can pop Kalk, it's a nice attack, but if you cannot pop Kalk, then what kind of attack is a Bluetooth on chip remote code execution? 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. But another funny attack would be to instead attack the Wi-Fi chip or maybe even the LTE chip. So to break the interchip separation instead of doing the same thing again of breaking into the operating system. And then I called Francesco and said like, hey, let's build speculative transmission. 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. And they cause interference in such a small device. So they need to arbitrate the channel access, which means they need to actually tell I'm sending a packet, can you please not send a packet right now and so on. And also need to tell priority and so on. And this is called a coexistence mechanism and it's a performance optimization. And of course, you could now also instead speculatively transmit a packet and use this to infer what the other cores are doing. So this was the initial attack idea. In the end, it turned out to be a bit more of a spectrum transmission, but this is the attack scheme. Of course, it requires a lot of exploitation before. So it requires the Bluetooth remote code execution or Wi-Fi remote code execution to then escalate into the other chip. But the interesting part here is, as this is a connection directly between the chips, you cannot plug it with the operating system. So there is a very nice attack vector that is hard to prevent. And if you look into a modern iPhone, this is what it roughly looks like. So you have the Bluetooth and the Wi-Fi chip, which are within a combo chip, but they still run on different ARM cores. And they are connected via the serial enhanced coexistence interface. This is what we are going to attack. The combo chip is also interconnected with an LTE chip. And this is using mobile wireless standards. And then you can also see that the Bluetooth daemon has fewer writes than the Wi-Fi daemon. And the Bluetooth chip is usually connected with UiD. The newer iPhones use PCI Express here. And now if you could escalate between the chips, you have newer text paths that become possible. 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. Or I could also try to infer timings in between those chips and so on. The spectra impact can be very different depending on how this coexistence interface is implemented. So first of all, the most obvious one is the denied of service. If one core denies transmission to another core, but it could also be information disclosure via timings or packet types and so on. And the worst case would be code execution. And for this one, you really need to screw up your implementation. When this attack has been first on the internet because of the blackhead abstract, someone started tweeting and giving it other names. And I have to say I also like the clear goals attack, but spectra is like the original name. Of course, it's harder to find this on the internet because spectra is just a very generic word. And now let's go for the Broadcom coexistence interface, which we are now going to exploit. This is also present in a couple of Cypress chips because Cypress acquired parts of Broadcom in 2016. So it's synonymous to be used here. So don't be confused if I mix up Broadcom and Cypress. It's all the same. Actually Broadcom is a very nice target because they don't do any firmware checks. 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. And there are no further checks, which means that there is no secure boot, no signature checking, etc. 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. And those chips are in many, many, many devices. So for example, all iPhones or MacBooks, IMAX and also the older Apple Watch system just wants to have a different one. The Samsung Galaxy S series, the older Google Nexus phones or Raspberry Pi is a couple of IoT devices and so on. So this is a very nice prototyping platform for all kinds of attacks. If you look into the older data sheets, you can also find a couple of data, still not everything, but the new data sheets just don't exist. So we need to live with what is there, what is documented. 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. And then there is a lot of stuff going on between those chips, which we are going to attack in the following. Nonetheless, they have different ARM cores. So this one has an ARM Cortex-M3, there's the Cortex-R4, and so on. So this is still separated in some ways. For understanding the attacks, now we need to understand the serial enhanced coexistence interface, which is used between Wi-Fi and Bluetooth. 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. To understand it, the best way is to actually separate Bluetooth and Wi-Fi. And in this setup, you can see that there is a Bluetooth and a Wi-Fi board by Cypress. 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. 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. 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. 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. And what is very interesting about this protocol already at this level is that the Bluetooth and Wi-Fi are sending with three mega-bolts over the serial interface. And three mega-bolts 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. So you can imagine how much data there is within the coexistence interface. 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. So each tiny peak there really has some information about the task that is running and other stuff that has priorities of packets. And in the last example, you can also see a Bluetooth keyboard, which has regular peaks that is then being sent by Wi-Fi as idle. So this is roughly what it looks like just to give you some idea about this protocol. In the first attack, we didn't even need to understand all the details of this. It's just a simple reconfiguration of this interface. 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. 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 and then Francesco just told me, well, if you don't understand it, just try breaking it, just write something in all those registers and see what breaks. And I found out when I write just apps into the CCI chip control, this crashes Wi-Fi. And more interestingly in this evaluation board setup, I could even see some voltage drop on the logic analyzer. This was very weird. And on some devices, this even causes a kernel panic because upon writing to the CCI chip control within Bluetooth, Wi-Fi might stop or even spam stuff over PCI Express and so on. And then there are very weird effects from this. 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. 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. And already this is sufficient to have a kernel panic on a lot of those devices. On some of them, it's also just Wi-Fi that restites and that's it. Now, this already looks very promising for such a simple attack. And because of this, we try to build more fancy attacks with this primitive. And this is what Francesco is now going to tell you about. Thanks, Giska, for introducing this part of the talk. Let's start describing the Broadcom Wi-Fi chipset. 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. Interestingly, low-level operations are always managed by the same piece of hardware that did not change much in 70 years. No matter which Wi-Fi chipset we are using, time-critical operations are managed by the same D11 microcontroller that coordinates five radiofrequency and DMA operations. Let's have a closer look to the low level. The D11 microcontroller runs the microcode, a short piece of software that keeps checking hardware conditions and triggers specific operations. We see here some code from the main loop that checks if the PHY started receiving a PLCP prehambl or if the current reception is terminated. In such cases, it will execute the corresponding handlers that will decide what to do with the current flight. This other piece of code is extracted from the part that schedules the transmission of an acknowledgement. We see the preparation of the reply frame that starts with D4 as usual. The D11 toolchain was created by Michael Buetsch in 2007. We incorporated it inside our Netman project and we periodically updated it by adding new instructions when a new chipset is introduced. As spotting the U-code in the ARM binary blob is easy, we can modify it to adding customized parts as we will see later. The D11 CPU coordinates many blocks. First of all, it controls the transmission and reception engines. It manages channel's access by scheduling transmissions and decides which received frames should be pushed to the ARM core. 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. The D11 has access to an eight 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. The D11 is equipped with general-purpose timers and with many different interfaces for talking to other parts of the chipset like the second interface. 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-off-light measurements. Let's now talk about the D11 coexistence interface. It includes quite a number of registers and a 64-bit buffer for receiving messages from the Bluetooth. Such messages are transmitted by Bluetooth every 1.25 ms, that is the minimum Bluetooth connection interval. They report to Wi-Fi the timing and type of all Bluetooth operations. Wi-Fi copies this information inside dedicated, shaky countdown timers that defer Wi-Fi operations and prevent collisions. On the opposite direction, Wi-Fi uses the Bluetooth transmission control register in red for granting Bluetooth access to the chat. The flow of messages in the two directions builds a grant-reject scheme. As we will see, in our attacks, we use the knowledge we collected on such registers for breaking such scheme. According to our analysis, more than 10% of the U-code is dedicated to coexistence. As in general, many other operations take much less code, we understand how much complex is the coexistence interface. Finally, by programming two boards for transmitting SEKI messages when receiving the same Wi-Fi beacon, we measured, with the help of an external FPGA, the jitter of the SEKI line. It added out to be Gaussian with 200 ns deviation, which is perfect for this application. So let's see how we broke the grant-reject scheme. We did that to see the effect when watching a movie that requires to download content over the Wi-Fi and send audio to a Bluetooth headset. At the bottom, in green, we see SEKI grant messages transmitted by the Wi-Fi. Bluetooth uses them for understanding when it can transmit audio to the headset. We introduced it into the U-code a few lines for configuring the Wi-Fi chipset remotely from the air interface. We can hence prevent the Wi-Fi from sending SEKI grant messages to Bluetooth. You see this happens between 2.6 and 3.5 seconds. During this interval, no more SEKI messages are transmitted, and in fact, we cannot hear any sound from the headset. We tested this both on an AXUS 5 and on undevelopment boards from Cyprus. This experiment clearly demonstrates that a denial of service attack from the Wi-Fi side against Bluetooth is possible. 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. These are the SEKI time diagrams when we have a keyboard connected over Bluetooth. Depending on the keyboard, we can observe SEKI messages transmitted every 15 or 30 ms. Bluetooth sends these SEKI messages to inform Wi-Fi that it is going to pull the keyboard so that Wi-Fi, the first channel access, mean Y. In this diagram, Wi-Fi is idle, so Wi-Fi always grants access to Bluetooth. This is what happens when somebody is actually typing on a keyboard. At the bottom, we have the periodic sequence of SEKI messages. On top, we have the key presses sniffed by Wireshark when capturing from the Bluetooth interface. 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. In between, we can see the HID data captured by Wireshark with the specific event ID that represents a key press. Below, we see SEKI messages that we filtered on the Wi-Fi chipset by selecting the same message type. This demonstrates that at the Wi-Fi side, we can easily distinguish SEKI messages related to key presses. 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. We hence believe that without any further protection, the SEKI interface can be used for mounting side-channel attacks. And we requested the CVE for reporting the associated vulnerability. Cisca, the ground is yours again. Thank you Francesco for the very detailed explanations about the Serial Hearts coexistence interface and attacks on it. There is still one thing mentioned in the datasheet, which was clearly missing, which is the WLAN RAM sharing. And in the following, we are also going to attack this. 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 the datasheet that you just couldn't find within the Serial Hearts coexistence interface. And for us, this was this WLAN RAM sharing. So it must be somewhere. It's in the datasheet errors just go into one direction here from to Wi-Fi. And we just didn't understand where it is and couldn't find it for quite a long time. 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 from a MacBook. And within those symbols, there suddenly were a few called WLAN buff something. So it looked a bit like probably the shared RAM, but it were just functions. And then I analyzed those functions. And there was one function that was pulling somewhere in the 6800000 region. And actually when I saw this, then I tried to read it. It sometimes crashes if you don't do it in the right order and so on. But in the beginning of the section, I actually saw, wow, there is a string 802.11 something on the device where I did this. And then I was like, probably I'm already in there. Still to confirm it, I instead write writing to it. And when I write to this, what happens is that quite often the Wi-Fi crashes. So within Bluetooth, I write into those registers and suddenly Wi-Fi crashes. And a nice part about a Wi-Fi crashes is that on a couple of devices, this is causing a crash dump. And this crash dump actually contains parts of the ROM image. 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 mapped into each other. And also it revealed a couple of pointers, function pointers. So within the function pointer table, I was just overwriting a couple of pointers. And it turned out that within this position, there is a pointer table. And when I write to this, I can get the program counter under control. So I can write to ROM, I can set the program counter. So I can have code execution. And that was really amazing. I have a demo video for this on a MacBook. The mapping is slightly different. So on the left-hand side, I use internal clue to write assembly instructions because I'm just writing within a function and not within a function pointer. And then on the right-hand side, you see the Wi-Fi crash logs on macOS. And you can see that I can get the program counter under control. And this is how fast this attack works. So just within Bluetooth, I can get code execution in Wi-Fi. The interesting part here is that I couldn't find this area on the Nexus 5. So either it's not mapped at all or it's mapped to a different region. Even though this was the one that I initially had as the idea like from this datasheet, there must be this Wi-Fi rum sharing. But so this one, I didn't find it. Then there are a couple of devices where within the ROM dump, you can even find the 68000 and so on. So you know that within the firmware, this is used and on those also the attack works. The fun part here is that the MacBook, I don't have it with me, I just have this dump. So I couldn't try it on my own on this MacBook, but at least I know it should work because the symbol is there. And in the newest devices, this registry is never ever mentioned in the firmware but still the attack works. So it's probably a feature that has been abandoned and it's no longer used, but still we can use it for this type of attack on all those devices. The even more fun part is that sometimes I got again issues with PCI Express. So why is that? On all those chips, I had no idea what exactly I was doing. So I mean, yes, there is the mapping, but I first of all need to get the chip to crash, to get this rum image. And then I need to load it into IDA and analyze it and somehow find a place to get code execution for each chip. And so I was just writing certain things. And then again, like sometimes finding a pattern again when I find the pattern like in the program counter then I probably have code execution. So this was roughly my approach. And then on a couple of devices, this turned out to be a very efficient puzzle. 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. So sometimes just Wi-Fi crashes, but sometimes even kernel panics. And this is interesting because there are of course also some memory areas that I used for the PCI Express queue between the Wi-Fi chip and the host and so on. Or it might just simply block something within the communication between the Wi-Fi chip and the host. And depending on this, it can already cause a reboot. So with the super simple fuzzer of just flipping some bytes or like exchanging some bytes, you can reboot devices. And this is a capture of this. I just use an iPhone 6 because on this one it's very fast. It also works on a couple of other devices. You can see first of all Wi-Fi is switched off. So that's on the left hand side. And then the device is already rebooting. Now you might wonder what the patch looks like. And I mean a lot of this is in hardware. So you cannot really patch it. But what I have seen in a couple of devices is that they are now blocking the communication. So after the Bluetooth chip is initialized by the Bluetooth demon, the Bluetooth chip is then blocking any write, read, run commands, or at least writing. The reading is only blocked on a few devices, but writing is blocked on all newer chips as far as I've seen. And now the thing is that this prevents at least attacks where the Bluetooth demon would try to get code execution within Wi-Fi. So that's like this path. But what is not prevented by this is if you have remote code execution over the air and then escalate into Wi-Fi, or if you just know that the timing between the Wi-Fi and Bluetooth is a fixed one by now and use the known timing, which is not random because of some things sent over the air, but actually like predictable because of coexistence schemes. This might also be a thing that's exploitable here. But at least they added this to the attack model that suddenly Bluetooth might be able to attack Wi-Fi and because of this, this part is now blocked because you can block this quite easily. And now I mentioned in the beginning that this might also apply to other chips. And now the question here is like, what are the chips? 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 and on the second last page, it already starts with the mobile wireless standards. And this is another serial protocol which is used between Wi-Fi and Bluetooth chips or Bluetooth chips and LTE. And they are also sending activity information and so on over UART. And then there is another thing that goes via the operating system to initially configure it. And this one is also used on iPhones. So I saw it on an iPhone, so it probably is also tickable on them. And because everyone has some proprietary coexistence features, we asked Broadcom if we can also include other manufacturers in the responsibly splurge process and they said, yes, we can. And so we informed a couple of those who at least mentioned that they have coexistence in their data sheets and so on. 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. So by definition, that wouldn't be attackable in the sense of you already have code execution either way, so Bluetooth remote code execution is automatically a Wi-Fi remote code execution. 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. 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. 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. 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. If you have further questions, there will be a Q&A session and you can of course also reach me on Twitter or you can write an email to Francesco and me. Thanks for listening.