Hello everyone and welcome to the talk Spectra, which is about new wireless escalation targets.
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. 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 mine, Jan, built a fuzzer 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 just 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 is just nicer for exploitation. And also,
if you can pop KALC, it's a nice attack. But if you cannot pop KALC,
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
and 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 priorities 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 expectation 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 block 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 UI, the newer iPhones
use PCI Express here. And now, if you could escalate between the chips, you have new attack 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 spectral impact can be very different depending on how this coexistence
interface is implemented. So first of all, the most obvious one is the denial 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 queer ghost 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,
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. 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 details, still not everything,
but the newer 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
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. So you can imagine
how much data there is within the Coexistence Interface. 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. So each tiny peak there really has some information about the task that
is running and other stuff that tells priorities of packets. 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. 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 GCI 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 GCI
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 restarts and that's it. 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.
And this is what Francesco is now going to tell you about.
Thanks Gisca 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,
critical operations are managed by the same D11 microcontroller that coordinates
PHY, radiofrequency and VMA 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 preamble, 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 PHY. 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 Buech in 2007. We incorporated it inside our Netman project and we periodically
update it by adding new instructions when a new chipset is introduced. As spotting the new code
in the ARM binary blob is easy, we can modify it 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 channels access by scheduling transmissions, and the sides 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 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. 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. 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. 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 milliseconds,
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 Secchi 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 chip. The flow of messages in the two directions builds a grant-reject scheme. As we
will see, in our attacks we used 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 Secchi messages when receiving the
same Wi-Fi beacon, we measured, with the help of an external FPGA, the jitter of the Secchi line.
It turned out to be Gaussian with 200 nanosecond deviation, which is perfect for this application.
So let's see how we broke the grant-reject scheme. 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.
At the bottom, in green, we see Secchi grant messages transmitted by the Wi-Fi. Bluetooth
uses them for understanding when it can transmit audio to the headset. We introduce 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 Secchi grant messages to Bluetooth. You see this happens between
2.6 and 3.5 seconds. During this interval no more Secchi messages are transmitted and, in fact,
we cannot hear any sound from the headset. We tested this both on a Nexus 5 and on
development boards from Cypress. 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 Secchi time diagrams when we have a keyboard connected over Bluetooth. Depending
on the keyboard, we can observe Secchi messages transmitted every 15 or 30 milliseconds. 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. 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 Secchi 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 a specific event ID
that represents a key press. Below we see Secchi 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
Secchi 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 Secchi interface can be used for mounting side channel attacks and we requested the CVE
for reporting the associated vulnerability. Francesca, the ground is yours again.
Thank you Francesco for the very detailed explanations about the serial enhanced coexistence
interface and attacks on it. 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.
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. 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...
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 the nice part about a Wi-Fi crash is that on a couple of
devices, this is causing a crash dump. And this crash dump actually contains parts of
the RAM 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 wrapped 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 if in
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 RAM, 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 glue 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 a 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 data sheet, there must be this Wi-Fi RAM sharing.
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 680000 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 register 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 ROM 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. And
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 are 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.
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. And 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 daemon, the Bluetooth chip is then
blocking any write RAM, read RAM 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 daemon 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 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. 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
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
attackable on them. And because everyone has some proprietary coexistence features, we asked Broadcom
if we can also include other manufacturers in the response disclosure 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.