start	end	text
2140	7520	Hello everyone and welcome to the talk Spectra, which is about new wireless escalation targets.
7620	13580	This is a joint work by me, Jeska and Francesco, who has been working a lot with Wi-Fi while I
13580	19180	have been working with Bluetooth in the past. And in this work, we join our abilities to build a
19180	27020	new attack scheme. So the motivation of this is as simple as this. I found a partial Bluetooth RCE
27860	32460	a while ago. And then a bit later, a student of mine, Jan, built a fuzzer Frankenstein,
32460	38540	which emulates the Bluetooth chips. And he also found a couple of more remote code executions.
38820	43340	And with this, I said like, yeah, that's a great chance. Now we can tour the world,
43340	49020	tell everyone like we have Bluetooth remote code execution, take my unicorn, travel with it,
49020	54760	and just show everyone. But the thing is that people said they are not too surprised about
54760	59280	Bluetooth remote code execution because, you know, Bluetooth after 22 years is
59280	64220	really indistinguishable from magic. And they kind of expected that it is broken.
65960	70900	And then people also told me, you know, there is Bluetooth RCE, there's Wi-Fi RCE.
70900	76840	And Wi-Fi RCE is much cooler because, first of all, Bluetooth, it's connected via UART,
76840	83220	and Wi-Fi is connected with PCI Express. That is just nicer for exploitation. And also,
83220	88940	if you can pop KALC, it's a nice attack. But if you cannot pop KALC,
88940	92680	then what kind of attack is a Bluetooth on-chip remote code execution?
93880	100220	So I was thinking, because now the idea is, of course, like I could try to like take the
100220	105280	Bluetooth RCE and then break into the operating system all the way up. But another funny attack
105280	111820	would be to instead attack the Wi-Fi chip or maybe even the LTE chip. So to break the interchip
111820	117040	separation instead of doing the same thing again of breaking into the operating system.
118560	124300	And then I called Francesco and said like, hey, let's build speculative transmission.
124640	130780	And the idea of the attack was that in a smartphone, you have the same frequency used
130780	136420	by Wi-Fi and Bluetooth and LTE has harmonics in the same spectrum. And they cause interference
136420	143220	and in such a small device. So they need to arbitrate the channel access, which means they
143220	148540	need to actually tell I'm sending a packet. Can you please not send a packet right now and so on
148540	154220	and also need to tell priorities and so on. And this is called a coexistence mechanism,
154220	158460	and it's a performance optimization. And of course, you could now also instead
159260	165140	speculatively transmit a packet and use this to infer what the other cores are doing. So this
165140	171280	was the initial attack idea. In the end, it turned out to be a bit more of a spectrum transmission,
171280	178460	but this is the attack scheme. Of course, it requires a lot of expectation before. So it
178460	183120	requires the Bluetooth remote code execution or Wi-Fi remote code execution to then escalate
183120	188460	into the other chip. But the interesting part here is, as this is a connection directly between
188460	195000	the chips, you cannot block it with the operating system. So there is a very nice attack vector that
195000	202540	is hard to prevent. And if you look into a modern iPhone, this is what it roughly looks like. So you
202540	208840	have the Bluetooth and the Wi-Fi chip, which are within a combo chip, but they still run on different
208840	214140	ARM cores. And they are connected via the serial enhanced coexistence interface. This is what we
214140	221940	are going to attack. The combo chip is also interconnected with an LTE chip, and this is
221940	227300	using mobile wireless standards. And then you can also see that the Bluetooth daemon has fewer
227300	233620	writes than the Wi-Fi daemon. And the Bluetooth chip is usually connected with UI, the newer iPhones
233620	239220	use PCI Express here. And now, if you could escalate between the chips, you have new attack paths
239220	246000	that become possible. So for example, I could now start from Bluetooth over the air and then escalate
246000	251920	into Wi-Fi and then go all the way up. Or I could also try to infer timings in between those
251920	259920	chips and so on. The spectral impact can be very different depending on how this coexistence
259920	265380	interface is implemented. So first of all, the most obvious one is the denial of service, if one
265380	270780	core denies transmission to another core. But it could also be information disclosure via timings
270780	276600	or packet types and so on. And the worst case would be code execution. And for this one, you really
276600	282160	need to screw up your implementation. When this attack has been first on the internet because of
282160	287060	the blackhead abstract, someone started tweeting and giving it other names. And I have to say,
287060	293980	I also like the queer ghost attack, but spectra is like the original name. Of course, it's harder
293980	298420	to find this on the internet because spectra is just a very generic word.
300860	306440	And now let's go for the Broadcom coexistence interface, which we are now going to exploit.
306600	313280	This is also present in a couple of Cypress chips because Cypress acquired parts of Broadcom in 2016.
313520	319440	So it's synonymous to be used here. So don't be confused if I mix up Broadcom and Cypress,
319440	326580	it's all the same. Actually, Broadcom is a very nice target because they don't do any firmware
326580	332980	checks. And no firmware checks means that if we are able to reverse engineer certain parts of the
332980	339220	firmware, then we can also patch it within Wi-Fi and within Bluetooth. And there are no further
339220	345420	checks, which means that there is no secure boot, no signature checking, etc. So you still need to
345420	352540	understand what is going on to patch such a chip, but then there are no further security measures
352540	358640	to prevent this. And those chips are in many, many, many devices. So for example, all iPhones,
358640	362920	MacBooks, iMacs and also the older Apple Watches, the newest ones have a different one,
362920	368160	the Samsung Galaxy S series, the older Google Nexus phones or Raspberry Pis, a couple of IoT
368160	374060	devices and so on. So this is a very nice prototyping platform for all kinds of attacks.
376280	381240	If you look into the older data sheets, you can also find a couple of details, still not everything,
381720	386200	but the newer data sheets just don't exist. So we need to live with what is there, what is
386200	391500	documented. And what you can see here, there's this Bluetooth chip, there is a Wi-Fi chip,
391500	398080	they share an antenna, so they need to arbitrate access onto this one. And then there is a lot of
398080	403180	stuff going on between those chips, which we are going to attack in the following. Nonetheless,
403180	407460	they have different ARM cores. So this one has an ARM Cortex-M3, there's the Cortex-R4
408040	411980	and so on. So this is still separated in some ways.
415170	420590	For understanding the attacks now, we need to understand the Serial Enhanced Coexistence
420590	425430	Interface, which is used between Wi-Fi and Bluetooth. It's also called ECI, so without
425430	430870	the serial, and GCI, which might be Global or Generic Coexistence Interface, but it's all used
430870	439870	in the same way in the data sheets. To understand it, the best way is to actually separate Bluetooth
439870	445250	and Wi-Fi. And in this setup, you can see that there is a Bluetooth and a Wi-Fi board by Cypress.
445310	449830	They don't have a shared antenna, so everything is separate, there are no side effects, and the
449830	454790	only connection that they have is the Serial Enhanced Coexistence Interface, which we can
454790	461110	now also intercept. So that means that we are actually able to observe each and every signal
461110	467590	that is sent between those two boards, and there is nothing else that is going on that could block
467730	475510	a transmission. If you look into this in detail, first of all we did the experiments of streaming
475510	481470	just some music over Bluetooth, and then on the Wi-Fi chip we did a scan for other Wi-Fis. You can
481470	486850	see a peak when you start the scan, actually it's two peaks, and then there are a couple of other
486850	493070	peaks when you get the scan results, and the end of the scan. And what is very interesting about
493070	498590	this protocol already at this level is that the Bluetooth and Wi-Fi are sending with three
498590	504150	megabytes over the Serial Interface, and three megabytes is also the same amount of data that is
504150	508850	sent from the Bluetooth chip to the host to send the actual music of the stream. So you can imagine
508850	515730	how much data there is within the Coexistence Interface. And now you can see that Bluetooth is
515730	522930	within each peak actually sending some data that is annotated in hex here, and also Wi-Fi
522930	529190	is sending some data. So each tiny peak there really has some information about the task that
529190	535670	is running and other stuff that tells priorities of packets. And in the last example you can also
535670	542070	see a Bluetooth keyboard which has regular peaks that is then being sent while Wi-Fi is idle. So
542070	547030	this is roughly what it looks like just to give you some idea about this protocol.
549380	556100	In the first attack we didn't even need to understand all the details of this. It's just a
556100	563380	simple reconfiguration of this interface. So there are a lot, a lot, a lot of registers that are mapped
563380	570700	into the Bluetooth ARM core that you can write into or read from. And actually I tried to understand
570700	576360	all of them in the very beginning, and you can also do fancy stuff with this, but I didn't
576360	581440	understand all of them. And then Francesco just told me, well if you don't understand it, just try
581440	586640	breaking it. Just write something in all those registers and see what breaks. And I found out
586640	593620	when I write just apps into the GCI chip control, this crashes Wi-Fi. And more interestingly in this
593620	598400	evaluation board setup I could even see some voltage drop on the logic analyzer. This was
598400	605940	very weird. And on some devices this even causes a kernel panic, because upon writing to the GCI
605940	612520	chip control within Bluetooth, Wi-Fi might stop or even spam stuff over PCI Express and so on. And
612520	619420	then there are very weird effects from this. I tested it on a couple of devices, so starting
619420	625640	from the Nexus 5, but then also going all the way up to the newest MacBooks and iPhones and so on,
625640	631940	and the Samsung Galaxy S10, S20. And what you can see here is that first of all, depending on the
631940	636560	date of the chip you have a slightly different scheme, but on the newest ones you just write apps
636560	643640	into one address. And already this is sufficient to have a kernel panic on a lot of those devices.
643640	650560	On some of them it's also just Wi-Fi that restarts and that's it. Now this already looks very promising
650560	656520	for such a simple attack, and because of this we tried to build more fancy attacks with this primitive.
656780	660040	And this is what Francesco is now going to tell you about.
664890	670370	Thanks Gisca for introducing this part of the talk. Let's start describing the Broadcom Wi-Fi
670370	675510	chipset. In the last two decades it evolved from a soft Mac to a full Mac implementation,
675510	680990	and functions that were originally running on the Linux host at the top are today offloaded by an
680990	686510	intermediate ARM core. Interestingly, low-level operations are always managed by the same piece
686510	692230	of hardware that did not change much in 70 years. No matter which Wi-Fi chipset we are using,
692230	697430	critical operations are managed by the same D11 microcontroller that coordinates
697430	703350	PHY, radiofrequency and VMA operations. Let's have a closer look to the low-level. The D11
703350	709410	microcontroller runs the microcode, a short piece of software that keeps checking hardware conditions
709410	715110	and triggers specific operations. We see here some code from the main loop that checks if the PHY
715110	720830	started receiving a PLCP preamble, or if the current reception is terminated. In such cases
720830	726050	it will execute the corresponding handlers that will decide what to do with the current PHY. This
726050	731410	other piece of code is extracted from the part that schedules the transmission of an acknowledgement.
731410	737270	We see the preparation of the reply frame that starts with D4 as usual. The D11 toolchain was
737270	744050	created by Michael Buech in 2007. We incorporated it inside our Netman project and we periodically
744050	749850	update it by adding new instructions when a new chipset is introduced. As spotting the new code
749850	756250	in the ARM binary blob is easy, we can modify it adding customized parts, as we will see later.
756250	761810	The D11 CPU coordinates many blocks. First of all, it controls the transmission and reception
761810	767890	engines, it manages channels access by scheduling transmissions, and the sides which received frames
767890	773510	should be pushed to the ARM core. It can configure the PHY and the radio, and it does so by running
773510	778990	the U-code that is loaded into the U-code memory by the ARM firmware during initialization.
778990	785670	The D11 has access to an 8 kilobyte shared memory where it keeps its configuration and state variables,
785670	791190	and it also accesses indirectly the ARM memory where packets ready for transmissions are queued
791190	796310	for deciding which packets can be transmitted or aggregated. The D11 is equipped with general
796310	801490	purpose timers and with many different interfaces for talking to other parts of the chipset,
801490	806470	like the Secchi interface. During the years it turned out to be a pretty flexible architecture
806470	811230	and we used it as a research platform for showcasing operations like jamming,
811230	815650	piggybacking schemes, and time-of-flight measurements. Let's now talk about the D11
815650	821630	coexistence interface. It includes quite a number of registers and a 64-bit buffer for receiving
821630	827890	messages from the Bluetooth. Such messages are transmitted by Bluetooth every 1.25 milliseconds,
827890	833290	that is the minimum Bluetooth connection interval. They report to Wi-Fi the timing and type of all
833290	838950	Bluetooth operations. Wi-Fi copies this information inside dedicated Secchi countdown
838950	844890	timers that defer Wi-Fi operations and prevent collisions. On the opposite direction,
844890	850470	Wi-Fi uses the Bluetooth transmission control register, in red, for granting Bluetooth access
850470	856630	to the chip. The flow of messages in the two directions builds a grant-reject scheme. As we
856630	861970	will see, in our attacks we used the knowledge we collected on such registers for breaking such
861970	868550	scheme. According to our analysis, more than 10% of the U-code is dedicated to coexistence. As in
868550	874930	general many other operations take much less code, we understand how much complex is the coexistence
874930	880610	interface. Finally, by programming two boards for transmitting Secchi messages when receiving the
880610	886830	same Wi-Fi beacon, we measured, with the help of an external FPGA, the jitter of the Secchi line.
886830	892410	It turned out to be Gaussian with 200 nanosecond deviation, which is perfect for this application.
892410	898530	So let's see how we broke the grant-reject scheme. We did that to see the effects when watching a
898530	905030	movie that requires to download content over the Wi-Fi and send audio to a Bluetooth headset.
905030	910810	At the bottom, in green, we see Secchi grant messages transmitted by the Wi-Fi. Bluetooth
910810	915890	uses them for understanding when it can transmit audio to the headset. We introduce it into the
915890	921690	U-code a few lines for configuring the Wi-Fi chipset remotely from the air interface. We can
921690	928130	hence prevent the Wi-Fi from sending Secchi grant messages to Bluetooth. You see this happens between
928130	935230	2.6 and 3.5 seconds. During this interval no more Secchi messages are transmitted and, in fact,
935230	940170	we cannot hear any sound from the headset. We tested this both on a Nexus 5 and on
940170	945950	development boards from Cypress. This experiment clearly demonstrates that a denial-of-service
945950	951610	attack from the Wi-Fi side against Bluetooth is possible. Let's take a closer look now at
951610	957250	the messages that Bluetooth sends to Wi-Fi and if we can use such information for an attack.
957250	962630	These are the Secchi time diagrams when we have a keyboard connected over Bluetooth. Depending
962630	968970	on the keyboard, we can observe Secchi messages transmitted every 15 or 30 milliseconds. Bluetooth
968970	975310	sends these Secchi messages to inform Wi-Fi that it is going to poll the keyboard so that Wi-Fi
975310	981810	defers channel access meanwhile. In this diagram Wi-Fi is idle, so Wi-Fi always grants access to
981810	987650	Bluetooth. This is what happens when somebody is actually typing on a keyboard. At the bottom we
987650	993570	have the periodic sequence of Secchi messages. On top we have the key presses sniffed by Wireshark
993570	998770	when capturing from the Bluetooth interface. As we are typing with moderate speed, each key press
998770	1003950	is separate from the others and we can also see the Bluetooth message with key release following
1003950	1010350	each key press. In between we can see the HID data captured by Wireshark with a specific event ID
1010350	1015990	that represents a key press. Below we see Secchi messages that we filtered on the Wi-Fi chipset by
1015990	1021730	selecting the same message type. This demonstrates that at the Wi-Fi side we can easily distinguish
1021730	1027370	Secchi messages related to key presses. This clearly demonstrates that having access to the
1027370	1032710	Wi-Fi chipset is enough for measuring key press timings with very accurate resolution and we know
1032710	1038010	that in some cases with the help of some artificial intelligence or classification technique this is
1038010	1043210	enough for guessing what a user is typing. We hence believe that without any further protection
1043210	1048930	the Secchi interface can be used for mounting side channel attacks and we requested the CVE
1048930	1054010	for reporting the associated vulnerability. Francesca, the ground is yours again.
1056050	1061430	Thank you Francesco for the very detailed explanations about the serial enhanced coexistence
1061430	1066710	interface and attacks on it. There is still one thing mentioned in the data sheet which was clearly
1066710	1072630	missing which is the WLAN RAM sharing and in the following we are also going to attack this.
1073290	1077850	I would call this effect when you spend too much time looking for very fancy side channels
1077850	1083770	and dig deeper into all of this and try to explore them while there is the one obvious thing in a
1083770	1088470	data sheet that you just couldn't find within the serial enhanced coexistence interface and for us
1088470	1094310	this was this WLAN RAM sharing so it must be somewhere it's in the data sheet errors just go
1094310	1100390	into one direction here from Bluetooth to Wi-Fi and we just didn't understand where it is and
1100390	1108730	couldn't find it for quite a long time. And the reason for this is that the Cypress boards come
1108730	1115470	with some development kit and within this there are some symbol leaks but the problem here is
1115470	1121770	there's nothing mentioned with WLAN and so there probably is no WLAN RAM sharing I thought maybe
1121770	1128550	it's just another word for the enhanced coexistence mappings but then there was also another part of
1128550	1133570	symbols and I was able to obtain a ROM image and it's not from a development board but actually
1133570	1163550	A little pause... and we are back...
1163570	1170390	The beginning of the section, I actually saw, wow, there is a string 802.11 something on
1170390	1174950	the device where I did this. And then I was like, probably I'm already in there. Still,
1174950	1180770	to confirm it, I instead write writing to it. And when I write to this, what happens
1180770	1186030	is that quite often the Wi-Fi crashes. So within Bluetooth, I write into those registers
1186030	1191230	and suddenly Wi-Fi crashes. And the nice part about a Wi-Fi crash is that on a couple of
1191230	1198190	devices, this is causing a crash dump. And this crash dump actually contains parts of
1198190	1202790	the RAM image. So I could write data that I know and try to find the same data again
1202790	1207530	to make the mapping and find like how Wi-Fi and Bluetooth are wrapped into each other.
1207820	1213550	And also it revealed a couple of pointers, function pointers. So within the function
1213550	1218550	pointer table, I was just overwriting a couple of pointers. And it turned out that if in
1218550	1222190	this position, there is a pointer table. And when I write to this, I can get the program
1222190	1227030	counter under control. So I can write to RAM, I can set the program counter. So I can have
1227030	1233490	code execution. And that was really amazing. I have a demo video for this on a MacBook.
1233550	1237710	The mapping is slightly different. So on the left hand side, I use internal glue to write
1238410	1242570	assembly instructions, because I'm just writing within a function and not within a function
1243150	1248190	pointer. And then on the right hand side, you see the Wi-Fi crash logs on macOS. And
1248190	1252770	you can see that I can get a program counter under control. And this is how fast this attack
1252770	1257130	works. So just within Bluetooth, I can get code execution in Wi-Fi.
1259550	1265090	The interesting part here is that I couldn't find this area on the Nexus 5. So either it's
1265090	1269710	not mapped at all, or it's mapped to a different region. Even though this was the one that
1269710	1275590	I initially had as the idea, like from this data sheet, there must be this Wi-Fi RAM sharing.
1275590	1281770	So this one, I didn't find it. Then there are a couple of devices where within the ROM dump,
1281770	1288750	you can even find the 680000 and so on. So you know that within the firmware, this is used.
1288750	1294190	And on those, also the attack works. The fun part here is that the MacBook, I don't have it with me.
1294190	1300310	I just have this dump. So I couldn't try it on my own on this MacBook. But at least I know it
1300310	1307430	should work because the symbol is there. And in the newest devices, this register is never ever
1307430	1313630	mentioned in the firmware, but still the attack works. So it's probably a feature that has been
1313630	1318910	abandoned, and it's no longer used. But still, we can use it for this type of attack on all those
1318910	1329220	devices. The even more fun part is that sometimes I got again issues with PCI Express. So why is
1329220	1336440	that? On all those chips, I had no idea what exactly I was doing. So I mean, yes, there is the
1336440	1341760	mapping, but I first of all need to get the chip to crash to get this ROM image. And then I need to
1341760	1347920	load it into IDA and analyze it and somehow find a place to get code execution for each chip.
1348240	1352520	And so I was just writing certain things. And then again, like sometimes finding a pattern again. And
1352520	1357340	when I find the pattern like in the program counter, then I probably have code execution.
1357340	1364200	So this was roughly my approach. And then on a couple of devices, this turned out to be a very
1364200	1370220	efficient puzzle. So just flipping a couple of bytes somewhere in the shared memory between Wi-Fi
1370220	1377200	and Bluetooth was sufficient to get kernel panics on a couple of devices. So sometimes just Wi-Fi
1377200	1382860	crashes, but sometimes even kernel panics. And this is interesting because there are of course also
1382860	1389060	some memory areas that are used for the PCI express queue between the Wi-Fi chip and the
1389060	1393920	host and so on. Or it might just simply block something within the communication between the
1393920	1399680	Wi-Fi chip and the host. And depending on this, it can already cause a reboot. So with the super
1399680	1407500	simple fuzzer of just flipping some bytes or like exchanging some bytes, you can reboot devices.
1407500	1413540	This is a capture of this. I just use an iPhone 6 because on this one it's very fast. It also
1413540	1419060	works on a couple of other devices. And you can see first of all Wi-Fi is switched off. So that's
1419060	1429100	on the left hand side and then the device is already rebooting. Now you might wonder what
1429100	1434700	the patch looks like. And I mean a lot of this is in hardware, so you cannot really patch it.
1434700	1440900	But what I have seen in a couple of devices is that they are now blocking the communication. So
1440900	1446860	after the Bluetooth chip is initialized by the Bluetooth daemon, the Bluetooth chip is then
1446860	1453960	blocking any write RAM, read RAM commands or at least writing. The reading is only blocked
1453960	1460400	on a few devices, but writing is blocked on all newer chips as far as I've seen.
1460400	1467300	And now the thing is that this prevents at least attacks where the Bluetooth daemon would try to
1467300	1472880	get code execution within Wi-Fi. So that's like this path. But what is not prevented by this is
1472880	1480120	if you have remote code execution over the air and then escalate into Wi-Fi. Or if you just know
1480120	1486280	that the timing between Wi-Fi and Bluetooth is a fixed one by now and use the known timing, which
1486280	1491660	is not random because of something sent over the air, but actually like predictable because of
1491660	1497800	coexistence schemes, this might also be a thing that's exploitable here. But at least they added
1497800	1503340	this to the attack model that suddenly Bluetooth might be able to attack Wi-Fi. And because of this,
1503340	1516260	this part is now blocked because you can block this quite easily. And now I mentioned in the
1516260	1523900	chips. If you look into the Bluetooth specification and read it backwards, because I mean I'm a reverse
1523900	1529120	engineer, so I also read the specification backwards obviously, what you can see on the
1529120	1533560	last page is the Bluetooth logo. And on the second last page, it already starts with the mobile
1533560	1542240	wireless standards. And this is another serial protocol which is used between Wi-Fi and Bluetooth
1542240	1549820	chips or Bluetooth chips and LTE. And they are also sending activity information and so on over
1549820	1554020	UART. And then there is another thing that goes via the operating system to initially
1555100	1561320	configure it. And this one is also used on iPhones. So I saw it on an iPhone, so it probably is also
1561320	1568520	attackable on them. And because everyone has some proprietary coexistence features, we asked Broadcom
1568520	1573700	if we can also include other manufacturers in the response disclosure process. And they said yes,
1573700	1579620	we can. And so we informed a couple of those who at least mentioned that they have coexistence in
1579620	1584540	their data sheets and so on. And some of their responses were like that this doesn't really
1584540	1591820	apply to them because there are some chips that have just one core that handles multiple wireless
1591820	1598800	protocols. So by definition, that wouldn't be attackable in the sense of you already have code
1598800	1603320	execution either way. So Bluetooth remote code execution is automatically a Wi-Fi remote code
1603320	1610180	execution. But of course, there might be other side channels like I can now from the timing of
1610180	1618900	Wi-Fi frames that I sent on an upper layer, maybe predict how the typing on a keyboard or something
1618900	1624260	was, for example, or how the activity was on the other wireless core. And this might be something
1624260	1629880	that could still be possible even though the code execution is kind of by design and cannot be
1629880	1637560	prevented, there might be further attacks. And as a summary, so what we reached is if you have a
1637560	1642580	Bluetooth remote code execution on a Broadcom chip, you can now cause driver kernel panics,
1642580	1647580	get information disclosure about Wi-Fi, and even code execution within Wi-Fi. And the other way
1647580	1652180	around, if you have a Wi-Fi remote code execution, you can now do denial of service against Bluetooth
1652180	1659000	and also get information disclosure within Bluetooth. If you have further questions, there
1659000	1663700	will be a Q&A session. And you can, of course, also reach me on Twitter, or you can write an email
1663700	1666840	to Francesco and me. Thanks for listening.