1
00:00:02,140 --> 00:00:07,520
Hello everyone and welcome to the talk Spectra, which is about new wireless escalation targets.

2
00:00:07,620 --> 00: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.

3
00:00:15,620 --> 00:00:20,240
And in this work, we join our abilities to build a new attack scheme.

4
00:00:21,240 --> 00:00:24,760
So the motivation of this is as simple as this.

5
00:00:24,760 --> 00:00:28,760
I found a partial Bluetooth RCE a while ago.

6
00:00:28,760 --> 00:00:34,320
And then a bit later, a student of mine, Jan, built a fuzzer Frankenstein, which emulates the Bluetooth chips.

7
00:00:34,320 --> 00:00:38,540
And he also found a couple of more remote code executions.

8
00:00:38,820 --> 00:00:42,080
And with this, I said like, yeah, that's a great chance.

9
00:00:42,080 --> 00: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.

10
00:00:50,840 --> 00: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.

11
00:01:01,580 --> 00:01:04,220
And they kind of expected that it is broken.

12
00:01:05,960 --> 00:01:10,900
And then people also told me, you know, there is Bluetooth RCE, there's Wi-Fi RCE.

13
00:01:10,900 --> 00: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.

14
00:01:18,940 --> 00:01:21,840
That is just nicer for exploitation.

15
00:01:21,840 --> 00:01:26,680
And also, if you can pop KALC, it's a nice attack.

16
00:01:26,680 --> 00:01:32,680
But if you cannot pop KALC, then what kind of attack is a Bluetooth on-chip remote code execution?

17
00:01:33,880 --> 00: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.

18
00:01:43,840 --> 00:01:50,300
But another funny attack would be to instead attack the Wi-Fi chip or maybe even the LTE chip.

19
00:01:50,300 --> 00:01:57,040
So to break the interchip separation instead of doing the same thing again of breaking into the operating system.

20
00:01:58,560 --> 00:02:04,300
And then I called Francesco and said like, hey, let's build speculative transmission.

21
00:02:04,640 --> 00: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.

22
00:02:14,980 --> 00:02:19,120
And they cause interference and in such a small device.

23
00:02:19,120 --> 00:02:25,960
So they need to arbitrate the channel access, which means they need to actually tell I'm sending a packet.

24
00:02:25,960 --> 00:02:31,040
Can you please not send a packet right now and so on and also need to tell priorities and so on.

25
00:02:31,040 --> 00:02:36,160
And this is called a coexistence mechanism, and it's a performance optimization.

26
00:02:36,400 --> 00: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.

27
00:02:44,840 --> 00:02:47,060
So this was the initial attack idea.

28
00:02:47,060 --> 00:02:53,380
In the end, it turned out to be a bit more of a spectrum transmission, but this is the attack scheme.

29
00:02:53,640 --> 00:02:57,880
Of course, it requires a lot of expectation before.

30
00:02:57,880 --> 00:03:04,420
So it requires the Bluetooth remote code execution or Wi-Fi remote code execution to then escalate into the other chip.

31
00:03:04,420 --> 00: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.

32
00:03:11,900 --> 00:03:16,420
So there is a very nice attack vector that is hard to prevent.

33
00:03:17,800 --> 00:03:22,200
And if you look into a modern iPhone, this is what it roughly looks like.

34
00:03:22,200 --> 00: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.

35
00:03:30,160 --> 00:03:33,600
And they are connected via the serial enhanced coexistence interface.

36
00:03:33,600 --> 00:03:35,420
This is what we are going to attack.

37
00:03:36,140 --> 00:03:43,820
The combo chip is also interconnected with an LTE chip, and this is using mobile wireless standards.

38
00:03:44,260 --> 00:03:48,940
And then you can also see that the Bluetooth daemon has fewer writes than the Wi-Fi daemon.

39
00:03:48,940 --> 00:03:55,060
And the Bluetooth chip is usually connected with UI, the newer iPhones use PCI Express here.

40
00:03:55,060 --> 00:04:00,580
And now, if you could escalate between the chips, you have new attack paths that become possible.

41
00:04:00,580 --> 00: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.

42
00:04:08,640 --> 00:04:13,500
Or I could also try to infer timings in between those chips and so on.

43
00:04:15,460 --> 00:04:21,360
The spectral impact can be very different depending on how this coexistence interface is implemented.

44
00:04:21,360 --> 00:04:27,580
So first of all, the most obvious one is the denial of service, if one core denies transmission to another core.

45
00:04:27,580 --> 00:04:32,940
But it could also be information disclosure via timings or packet types and so on.

46
00:04:33,020 --> 00:04:35,620
And the worst case would be code execution.

47
00:04:35,620 --> 00:04:38,840
And for this one, you really need to screw up your implementation.

48
00:04:39,680 --> 00: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.

49
00:04:46,320 --> 00:04:52,120
And I have to say, I also like the queer ghost attack, but spectra is like the original name.

50
00:04:52,120 --> 00:04:58,420
Of course, it's harder to find this on the internet because spectra is just a very generic word.

51
00:05:00,860 --> 00:05:06,440
And now let's go for the Broadcom coexistence interface, which we are now going to exploit.

52
00:05:06,600 --> 00:05:13,280
This is also present in a couple of Cypress chips because Cypress acquired parts of Broadcom in 2016.

53
00:05:13,520 --> 00:05:16,400
So it's synonymous to be used here.

54
00:05:16,400 --> 00:05:21,040
So don't be confused if I mix up Broadcom and Cypress, it's all the same.

55
00:05:22,520 --> 00:05:27,300
Actually, Broadcom is a very nice target because they don't do any firmware checks.

56
00:05:27,300 --> 00: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.

57
00:05:38,080 --> 00:05:44,340
And there are no further checks, which means that there is no secure boot, no signature checking, etc.

58
00:05:44,340 --> 00: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.

59
00:05:54,340 --> 00:05:57,180
And those chips are in many, many, many devices.

60
00:05:57,180 --> 00: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.

61
00:06:09,120 --> 00:06:14,060
So this is a very nice prototyping platform for all kinds of attacks.

62
00:06:16,280 --> 00: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.

63
00:06:24,060 --> 00:06:27,140
So we need to live with what is there, what is documented.

64
00:06:27,160 --> 00: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.

65
00:06:36,440 --> 00: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.

66
00:06:42,700 --> 00:06:44,600
Nonetheless, they have different ARM cores.

67
00:06:44,600 --> 00:06:48,820
So this one has an ARM Cortex-M3, there's the Cortex-R4 and so on.

68
00:06:48,820 --> 00:06:51,980
So this is still separated in some ways.

69
00:06:55,170 --> 00: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.

70
00:07:03,210 --> 00: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.

71
00:07:15,070 --> 00:07:20,690
To understand it, the best way is to actually separate Bluetooth and Wi-Fi.

72
00:07:20,690 --> 00:07:25,250
And in this setup, you can see that there is a Bluetooth and a Wi-Fi board by Cypress.

73
00:07:25,310 --> 00: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.

74
00:07:36,530 --> 00: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.

75
00:07:50,830 --> 00: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.

76
00:08:01,130 --> 00: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.

77
00:08:11,190 --> 00: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.

78
00:08:28,210 --> 00:08:33,370
So you can imagine how much data there is within the Coexistence Interface.

79
00:08:34,250 --> 00: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.

80
00:08:44,390 --> 00: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.

81
00:08:53,050 --> 00: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.

82
00:09:01,910 --> 00:09:07,030
So this is roughly what it looks like just to give you some idea about this protocol.

83
00:09:09,380 --> 00:09:14,880
In the first attack we didn't even need to understand all the details of this.

84
00:09:14,880 --> 00:09:18,860
It's just a simple reconfiguration of this interface.

85
00:09:18,920 --> 00: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.

86
00:09:28,380 --> 00: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.

87
00:09:37,520 --> 00:09:42,100
And then Francesco just told me, well if you don't understand it, just try breaking it.

88
00:09:42,100 --> 00:09:45,540
Just write something in all those registers and see what breaks.

89
00:09:45,940 --> 00:09:51,940
And I found out when I write just apps into the GCI chip control, this crashes Wi-Fi.

90
00:09:51,940 --> 00:09:57,780
And more interestingly in this evaluation board setup I could even see some voltage drop on the logic analyzer.

91
00:09:57,780 --> 00:09:59,540
This was very weird.

92
00:09:59,700 --> 00: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.

93
00:10:12,400 --> 00:10:15,780
And then there are very weird effects from this.

94
00:10:16,620 --> 00: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.

95
00:10:28,220 --> 00: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.

96
00:10:38,900 --> 00:10:43,640
And already this is sufficient to have a kernel panic on a lot of those devices.

97
00:10:43,640 --> 00:10:47,460
On some of them it's also just Wi-Fi that restarts and that's it.

98
00:10:48,620 --> 00: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.

99
00:10:56,780 --> 00:11:00,040
And this is what Francesco is now going to tell you about.

100
00:11:04,890 --> 00:11:08,010
Thanks Gisca for introducing this part of the talk.

101
00:11:08,010 --> 00:11:11,030
Let's start describing the Broadcom Wi-Fi chipset.

102
00:11:11,030 --> 00: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.

103
00:11:22,490 --> 00:11:29,690
Interestingly, low-level operations are always managed by the same piece of hardware that did not change much in 70 years.

104
00:11:29,690 --> 00: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.

105
00:11:40,350 --> 00:11:42,790
Let's have a closer look to the low-level.

106
00:11:42,790 --> 00:11:51,530
The D11 microcontroller runs the microcode, a short piece of software that keeps checking hardware conditions and triggers specific operations.

107
00:11:51,530 --> 00: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.

108
00:12:00,110 --> 00:12:05,850
In such cases it will execute the corresponding handlers that will decide what to do with the current PHY.

109
00:12:05,850 --> 00:12:11,410
This other piece of code is extracted from the part that schedules the transmission of an acknowledgement.

110
00:12:11,410 --> 00:12:15,870
We see the preparation of the reply frame that starts with D4 as usual.

111
00:12:15,870 --> 00:12:20,410
The D11 toolchain was created by Michael Buech in 2007.

112
00:12:20,410 --> 00: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.

113
00:12:28,510 --> 00: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.

114
00:12:36,250 --> 00:12:39,130
The D11 CPU coordinates many blocks.

115
00:12:39,130 --> 00: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.

116
00:12:49,850 --> 00: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.

117
00:12:58,990 --> 00: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.

118
00:13:14,470 --> 00: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.

119
00:13:23,350 --> 00: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.

120
00:13:33,870 --> 00:13:37,370
Let's now talk about the D11 coexistence interface.

121
00:13:37,370 --> 00:13:43,050
It includes quite a number of registers and a 64-bit buffer for receiving messages from the Bluetooth.

122
00:13:43,050 --> 00:13:50,030
Such messages are transmitted by Bluetooth every 1.25 milliseconds, that is the minimum Bluetooth connection interval.

123
00:13:50,030 --> 00:13:54,710
They report to Wi-Fi the timing and type of all Bluetooth operations.

124
00:13:54,710 --> 00:14:03,350
Wi-Fi copies this information inside dedicated Secchi countdown timers that defer Wi-Fi operations and prevent collisions.

125
00:14:03,350 --> 00:14:11,290
On the opposite direction, Wi-Fi uses the Bluetooth transmission control register, in red, for granting Bluetooth access to the chip.

126
00:14:11,290 --> 00:14:16,210
The flow of messages in the two directions builds a grant-reject scheme.

127
00:14:16,210 --> 00:14:22,430
As we will see, in our attacks we used the knowledge we collected on such registers for breaking such scheme.

128
00:14:22,430 --> 00:14:28,210
According to our analysis, more than 10% of the U-code is dedicated to coexistence.

129
00:14:28,210 --> 00:14:35,750
As in general many other operations take much less code, we understand how much complex is the coexistence interface.

130
00:14:35,750 --> 00: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.

131
00:14:46,830 --> 00:14:52,410
It turned out to be Gaussian with 200 nanosecond deviation, which is perfect for this application.

132
00:14:52,410 --> 00:14:55,570
So let's see how we broke the grant-reject scheme.

133
00:14:55,570 --> 00: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.

134
00:15:04,850 --> 00:15:09,810
At the bottom, in green, we see Secchi grant messages transmitted by the Wi-Fi.

135
00:15:09,810 --> 00:15:14,590
Bluetooth uses them for understanding when it can transmit audio to the headset.

136
00:15:14,590 --> 00:15:21,410
We introduce it into the U-code a few lines for configuring the Wi-Fi chipset remotely from the air interface.

137
00:15:21,410 --> 00:15:26,590
We can hence prevent the Wi-Fi from sending Secchi grant messages to Bluetooth.

138
00:15:26,590 --> 00:15:30,830
You see this happens between 2.6 and 3.5 seconds.

139
00:15:30,830 --> 00:15:37,410
During this interval no more Secchi messages are transmitted and, in fact, we cannot hear any sound from the headset.

140
00:15:37,410 --> 00:15:42,290
We tested this both on a Nexus 5 and on development boards from Cypress.

141
00:15:42,290 --> 00:15:49,630
This experiment clearly demonstrates that a denial-of-service attack from the Wi-Fi side against Bluetooth is possible.

142
00:15:49,630 --> 00: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.

143
00:15:57,250 --> 00:16:02,270
These are the Secchi time diagrams when we have a keyboard connected over Bluetooth.

144
00:16:02,270 --> 00:16:08,710
Depending on the keyboard, we can observe Secchi messages transmitted every 15 or 30 milliseconds.

145
00:16:08,710 --> 00: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.

146
00:16:17,410 --> 00:16:22,530
In this diagram Wi-Fi is idle, so Wi-Fi always grants access to Bluetooth.

147
00:16:22,530 --> 00:16:26,730
This is what happens when somebody is actually typing on a keyboard.

148
00:16:26,730 --> 00:16:30,330
At the bottom we have the periodic sequence of Secchi messages.

149
00:16:30,330 --> 00:16:36,010
On top we have the key presses sniffed by Wireshark when capturing from the Bluetooth interface.

150
00:16:36,010 --> 00: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.

151
00:16:45,070 --> 00:16:52,270
In between we can see the HID data captured by Wireshark with a specific event ID that represents a key press.

152
00:16:52,270 --> 00:16:57,890
Below we see Secchi messages that we filtered on the Wi-Fi chipset by selecting the same message type.

153
00:16:57,890 --> 00:17:04,550
This demonstrates that at the Wi-Fi side we can easily distinguish Secchi messages related to key presses.

154
00:17:04,550 --> 00: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.

155
00:17:20,450 --> 00: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.

156
00:17:31,810 --> 00:17:34,010
Francesca, the ground is yours again.

157
00:17:36,050 --> 00:17:43,150
Thank you Francesco for the very detailed explanations about the serial enhanced coexistence interface and attacks on it.

158
00:17:43,150 --> 00: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.

159
00:17:53,290 --> 00: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.

160
00:18:24,610 --> 00: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...

161
00:19:23,570 --> 00: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.

162
00:19:31,630 --> 00:19:34,310
And then I was like, probably I'm already in there.

163
00:19:34,350 --> 00:19:38,350
Still, to confirm it, I instead write writing to it.

164
00:19:38,570 --> 00:19:43,930
And when I write to this, what happens is that quite often the Wi-Fi crashes.

165
00:19:43,930 --> 00:19:48,530
So within Bluetooth, I write into those registers and suddenly Wi-Fi crashes.

166
00:19:48,530 --> 00: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.

167
00:19:54,570 --> 00:19:59,030
And this crash dump actually contains parts of the RAM image.

168
00:19:59,030 --> 00: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.

169
00:20:07,820 --> 00:20:12,570
And also it revealed a couple of pointers, function pointers.

170
00:20:12,570 --> 00:20:16,770
So within the function pointer table, I was just overwriting a couple of pointers.

171
00:20:16,770 --> 00:20:20,450
And it turned out that if in this position, there is a pointer table.

172
00:20:20,450 --> 00:20:23,330
And when I write to this, I can get the program counter under control.

173
00:20:23,330 --> 00:20:26,050
So I can write to RAM, I can set the program counter.

174
00:20:26,090 --> 00:20:28,110
So I can have code execution.

175
00:20:28,390 --> 00:20:30,330
And that was really amazing.

176
00:20:30,930 --> 00:20:33,490
I have a demo video for this on a MacBook.

177
00:20:33,550 --> 00:20:34,950
The mapping is slightly different.

178
00:20:34,950 --> 00: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.

179
00:20:43,850 --> 00:20:48,070
And then on the right hand side, you see the Wi-Fi crash logs on macOS.

180
00:20:48,070 --> 00:20:51,250
And you can see that I can get a program counter under control.

181
00:20:51,490 --> 00:20:53,850
And this is how fast this attack works.

182
00:20:53,850 --> 00:20:57,130
So just within Bluetooth, I can get code execution in Wi-Fi.

183
00:20:59,550 --> 00:21:04,190
The interesting part here is that I couldn't find this area on the Nexus 5.

184
00:21:04,190 --> 00:21:08,010
So either it's not mapped at all, or it's mapped to a different region.

185
00:21:08,010 --> 00: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.

186
00:21:15,590 --> 00:21:17,730
So this one, I didn't find it.

187
00:21:17,770 --> 00:21:25,290
Then there are a couple of devices where within the ROM dump, you can even find the 680000 and so on.

188
00:21:25,290 --> 00:21:28,750
So you know that within the firmware, this is used.

189
00:21:28,750 --> 00:21:31,030
And on those, also the attack works.

190
00:21:31,110 --> 00:21:34,190
The fun part here is that the MacBook, I don't have it with me.

191
00:21:34,190 --> 00:21:35,630
I just have this dump.

192
00:21:35,630 --> 00:21:38,590
So I couldn't try it on my own on this MacBook.

193
00:21:38,590 --> 00:21:42,450
But at least I know it should work because the symbol is there.

194
00:21:42,830 --> 00:21:51,570
And in the newest devices, this register is never ever mentioned in the firmware, but still the attack works.

195
00:21:51,570 --> 00:21:55,750
So it's probably a feature that has been abandoned, and it's no longer used.

196
00:21:55,750 --> 00:21:59,890
But still, we can use it for this type of attack on all those devices.

197
00:22:02,620 --> 00:22:08,380
The even more fun part is that sometimes I got again issues with PCI Express.

198
00:22:08,400 --> 00:22:09,920
So why is that?

199
00:22:10,960 --> 00:22:14,880
On all those chips, I had no idea what exactly I was doing.

200
00:22:14,880 --> 00: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.

201
00:22:20,920 --> 00: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.

202
00:22:28,240 --> 00:22:30,020
And so I was just writing certain things.

203
00:22:30,020 --> 00:22:32,320
And then again, like sometimes finding a pattern again.

204
00:22:32,320 --> 00:22:37,340
And when I find the pattern like in the program counter, then I probably have code execution.

205
00:22:37,340 --> 00:22:40,420
So this was roughly my approach.

206
00:22:40,860 --> 00:22:45,100
And then on a couple of devices, this turned out to be a very efficient puzzle.

207
00:22:45,100 --> 00: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.

208
00:22:56,040 --> 00:22:59,760
So sometimes just Wi-Fi crashes, but sometimes even kernel panics.

209
00:22:59,980 --> 00: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.

210
00:23:10,100 --> 00:23:15,300
Or it might just simply block something within the communication between the Wi-Fi chip and the host.

211
00:23:15,300 --> 00:23:18,780
And depending on this, it can already cause a reboot.

212
00:23:18,780 --> 00:23:27,500
So with the super simple fuzzer of just flipping some bytes or like exchanging some bytes, you can reboot devices.

213
00:23:27,500 --> 00:23:29,800
This is a capture of this.

214
00:23:29,920 --> 00:23:33,240
I just use an iPhone 6 because on this one it's very fast.

215
00:23:33,240 --> 00:23:35,440
It also works on a couple of other devices.

216
00:23:35,780 --> 00:23:38,320
And you can see first of all Wi-Fi is switched off.

217
00:23:38,320 --> 00:23:43,160
So that's on the left hand side and then the device is already rebooting.

218
00:23:47,560 --> 00:23:50,460
Now you might wonder what the patch looks like.

219
00:23:50,560 --> 00:23:54,700
And I mean a lot of this is in hardware, so you cannot really patch it.

220
00:23:54,700 --> 00:24:00,860
But what I have seen in a couple of devices is that they are now blocking the communication.

221
00:24:00,860 --> 00: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.

222
00:24:12,660 --> 00: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.

223
00:24:20,400 --> 00: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.

224
00:24:29,700 --> 00:24:31,200
So that's like this path.

225
00:24:31,200 --> 00: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.

226
00:24:38,840 --> 00: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.

227
00:24:56,140 --> 00:25:02,500
But at least they added this to the attack model that suddenly Bluetooth might be able to attack Wi-Fi.

228
00:25:02,500 --> 00:25:06,380
And because of this, this part is now blocked because you can block this quite easily.

229
00:25:08,800 --> 00:25:17,240
And now I mentioned in the chips.

230
00:25:18,020 --> 00: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.

231
00:25:30,600 --> 00:25:34,880
And on the second last page, it already starts with the mobile wireless standards.

232
00:25:35,900 --> 00:25:44,840
And this is another serial protocol which is used between Wi-Fi and Bluetooth chips or Bluetooth chips and LTE.

233
00:25:45,160 --> 00:25:50,660
And they are also sending activity information and so on over UART.

234
00:25:50,660 --> 00:25:56,280
And then there is another thing that goes via the operating system to initially configure it.

235
00:25:56,280 --> 00:25:58,560
And this one is also used on iPhones.

236
00:25:58,560 --> 00:26:02,680
So I saw it on an iPhone, so it probably is also attackable on them.

237
00:26:03,520 --> 00: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.

238
00:26:12,840 --> 00:26:14,700
And they said yes, we can.

239
00:26:14,800 --> 00: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.

240
00:26:21,720 --> 00: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.

241
00:26:32,780 --> 00:26:40,220
So by definition, that wouldn't be attackable in the sense of you already have code execution either way.

242
00:26:40,220 --> 00:26:44,340
So Bluetooth remote code execution is automatically a Wi-Fi remote code execution.

243
00:26:44,540 --> 00: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.

244
00:27:03,440 --> 00: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.

245
00:27:14,320 --> 00: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.

246
00:27:27,000 --> 00: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.

247
00:27:37,460 --> 00:27:40,500
If you have further questions, there will be a Q&A session.

248
00:27:40,520 --> 00:27:45,520
And you can, of course, also reach me on Twitter, or you can write an email to Francesco and me.

249
00:27:45,740 --> 00:27:46,840
Thanks for listening.