1
00:00:00,000 --> 00:00:18,380
35c3 preroll music
2
00:00:20,130 --> 00:00:27,630
Herald: So, Dennis, the left speaker,
finished his M.Sc. in IT security this
3
00:00:27,630 --> 00:00:33,180
year. The next talk is based on his master
thesis, InternalBlue, which is a Bluetooth
4
00:00:33,180 --> 00:00:38,700
experimentation framework for which he
even received a prize. Jiska, the right
5
00:00:38,700 --> 00:00:45,229
speaker, or for you left speaker, has been
his supervisor during the thesis and she
6
00:00:45,229 --> 00:00:49,969
loves breaking things. After several talks
about wireless security, software-defined
7
00:00:49,969 --> 00:00:55,199
radio and Fitbits, she is now talking
about Bluetooth. Please welcome on stage
8
00:00:55,199 --> 00:01:00,219
Dennis Mantz and Jiska Classen to their
talk "Dissecting Broadcom Bluetooth".
9
00:01:00,219 --> 00:01:06,941
Applause
Dennis: Yeah. Thank you for the
10
00:01:06,941 --> 00:01:10,740
introduction and welcome you all to our
talk. I'm Dennis and as said I choose
11
00:01:10,740 --> 00:01:16,810
Bluetooth as the topic for my master's
thesis and the outcome basically was I
12
00:01:16,810 --> 00:01:19,990
reverse engineered the firmware of a
Bluetooth controller which was
13
00:01:19,990 --> 00:01:24,039
manufactured by Broadcom, and I built a
little experimentation framework around
14
00:01:24,039 --> 00:01:27,950
it. And today we are not only going to
present the framework, but also various
15
00:01:27,950 --> 00:01:33,130
kinds of use cases around it, and we also
brought along some demos. Now, if you
16
00:01:33,130 --> 00:01:37,409
start such a big reversing project you
certainly know that this will not be an
17
00:01:37,409 --> 00:01:41,659
easy task and also quite time consuming.
So you might want to ask: why did we do
18
00:01:41,659 --> 00:01:48,539
that in the first place? So there are
several good reasons. For one, dissecting
19
00:01:48,539 --> 00:01:53,350
the firmware and exploring it for
reverse engineering is really helpful if
20
00:01:53,350 --> 00:01:56,890
you want to get insights from a security
perspective. And this is what I had in
21
00:01:56,890 --> 00:02:01,250
mind when I first started my thesis. But
then secondly and even better, once you're
22
00:02:01,250 --> 00:02:05,819
able to modify the firmware you can
actually leverage this fully featured and
23
00:02:05,819 --> 00:02:10,270
working Bluetooth implementation to be
your very own experimentation platform, where
24
00:02:10,270 --> 00:02:16,480
you can add new features or can also alter
existing behavior, and it almost feels
25
00:02:16,480 --> 00:02:20,800
like you can add a kind of open source
touch to a closed source and proprietary
26
00:02:20,800 --> 00:02:25,950
platform which I really like about this
project. Certainly this requires a certain
27
00:02:25,950 --> 00:02:31,130
background in many different departments
like security, code analysis, wireless
28
00:02:31,130 --> 00:02:36,510
signals, embedded programming, and also
not every researcher has resources and
29
00:02:36,510 --> 00:02:42,159
time to do such a reverse engineering
project, but we think that the outcomes of
30
00:02:42,159 --> 00:02:46,709
this project are really helpful and
beneficial for the security community. So,
31
00:02:46,709 --> 00:02:50,819
and last but not least we actually really
like reverse engineering. So we already
32
00:02:50,819 --> 00:02:55,129
had great experiences with similar
projects in the past. For example, some of
33
00:02:55,129 --> 00:02:59,090
you might know the NexMon project, where
we reverse engineered and also modified
34
00:02:59,090 --> 00:03:05,960
the firmware of a Wi-Fi controller. Okay,
before we show our work, we first have to
35
00:03:05,960 --> 00:03:09,879
introduce a few Bluetooth protocols which
we will be mentioning quite a lot
36
00:03:09,879 --> 00:03:15,390
throughout this talk. So the first one
would be the host controller interface.
37
00:03:15,390 --> 00:03:20,390
Some of you might know that, it's the HCI,
and it's a protocol layer between the
38
00:03:20,390 --> 00:03:25,030
Bluetooth controller and the host system,
where the health system would be for
39
00:03:25,030 --> 00:03:29,930
example an Android phone, or iOS, or
Linux, or any other operating system which
40
00:03:29,930 --> 00:03:34,310
implements those upper layers of the
Bluetooth protocol stack, and all the
41
00:03:34,310 --> 00:03:38,429
lower layers are actually implemented
inside the Bluetooth controller. And one
42
00:03:38,429 --> 00:03:43,549
of them would be for example the Link
Manager Protocol, the LMP. And this one is
43
00:03:43,549 --> 00:03:48,240
also really interesting. It actually
manages connections to other remote
44
00:03:48,240 --> 00:03:54,870
Bluetooth devices. For example, pairing is
also done on this protocol layer. And
45
00:03:54,870 --> 00:03:58,760
what's an interesting difference is that
the Link Manager Protocol is actually
46
00:03:58,760 --> 00:04:03,540
transmitted over the air to communicate
with other devices, whereas the HCI
47
00:04:03,540 --> 00:04:07,709
protocol is only used locally to
communicate between the operating system
48
00:04:07,709 --> 00:04:14,180
and the Bluetooth controller. And another
interesting fact to know is that the HCI
49
00:04:14,180 --> 00:04:20,269
is actually able to be observable from the
host site. So if you maybe tried to capture
50
00:04:20,269 --> 00:04:24,420
on a Bluetooth interface in Linux before,
or if you turned on the BT snoop log
51
00:04:24,420 --> 00:04:28,880
feature under the development settings in
Android, you probably have seen HCI packets
52
00:04:28,880 --> 00:04:33,530
in Wireshark before, because this is an
easy task to do. However you probably did
53
00:04:33,530 --> 00:04:37,750
not see LMP packets in Wireshark before,
because this protocol layer is actually
54
00:04:37,750 --> 00:04:41,910
implemented inside the controller and it's
not observable from the host side. You
55
00:04:41,910 --> 00:04:45,100
won't see those packets if you just
capture on a Bluetooth interface because
56
00:04:45,100 --> 00:04:50,710
you can only see what's above the HCI
layer. And so the other thing is that you
57
00:04:50,710 --> 00:04:55,310
cannot also simply sniff this from the air
because Bluetooth has frequency hopping
58
00:04:55,310 --> 00:04:59,920
and encryption. So it's a lot harder to
sniff those packets from the air just as
59
00:04:59,920 --> 00:05:06,890
with Wi-Fi for example. But today we try
to change that. Now I will introduce the
60
00:05:06,890 --> 00:05:10,330
framework I developed and show its
features, and later we go into more
61
00:05:10,330 --> 00:05:16,770
details and also present some demos. As
already mentioned, we named the framework
62
00:05:16,770 --> 00:05:21,790
InternalBlue. It's open source and you can
find it on GitHub and currently it's only
63
00:05:21,790 --> 00:05:26,200
compatible with the Nexus 5 if you want to
use all of its features, but we are also
64
00:05:26,200 --> 00:05:30,250
working to port it to other Bluetooth
chips in other smartphones, and also other
65
00:05:30,250 --> 00:05:35,990
platforms like the Raspberry Pi, and yeah,
soon you will have more devices which are
66
00:05:35,990 --> 00:05:39,940
supported by this framework. We also
already gave a talk where we introduced
67
00:05:39,940 --> 00:05:44,010
the framework and give some details about
the internals and how it works. So if
68
00:05:44,010 --> 00:05:47,110
you're interested and want to learn more
then you should check out our previous
69
00:05:47,110 --> 00:05:50,710
talk which was also recorded and you can
find a link down at the bottom of the
70
00:05:50,710 --> 00:05:56,910
slide as well. Basically in a nutshell we
use vendor specific HCI commands which are
71
00:05:56,910 --> 00:06:01,900
implemented by Broadcom and allow us to
read out and modify the firmware while the
72
00:06:01,900 --> 00:06:06,580
chip is actually running. And on top of
this, we basically implemented a Python
73
00:06:06,580 --> 00:06:11,870
API to interact with the firmware, and we
use this API to then implement all kinds
74
00:06:11,870 --> 00:06:16,680
of features which we find interesting. For
example one of the first things we did was
75
00:06:16,680 --> 00:06:22,590
implementing such a LMP monitoring mode so
that we can finally see LMP traffic on our
76
00:06:22,590 --> 00:06:27,490
laptop in Wireshark. And what comes along
with this is that we are also able to
77
00:06:27,490 --> 00:06:32,610
inject arbitrary LMP packets inside
existing Bluetooth connections. And this
78
00:06:32,610 --> 00:06:36,340
turned out to be also very interesting
because then we can test how other devices
79
00:06:36,340 --> 00:06:40,770
react to maybe packets they don't accept
or yeah, at least it's very good for
80
00:06:40,770 --> 00:06:45,400
experimentation and for example we use
this to write a little proof of concept
81
00:06:45,400 --> 00:06:50,280
script for the fixed coordinate invalid
curve attack that was released this
82
00:06:50,280 --> 00:06:54,020
summer, not by us but by other
researchers, and we were able to actually
83
00:06:54,020 --> 00:06:59,190
prove that other devices are vulnerable to
this attack. So this is a really helpful
84
00:06:59,190 --> 00:07:06,880
and practical tool. Also, at some point we
found a crash our own. So we found back in
85
00:07:06,880 --> 00:07:12,030
some older Broadcom firmwares which allows
us to remotely crash the firmware in some
86
00:07:12,030 --> 00:07:17,440
of the Broadcom chips, and in some cases
we are even able to execute a limited set
87
00:07:17,440 --> 00:07:21,440
of functions, so this might be even more
interesting than just a crash - but more
88
00:07:21,440 --> 00:07:27,640
on that later. Now if you first start with
the main thing about this is, how do we
89
00:07:27,640 --> 00:07:33,090
actually modify the firmware, How is
patching being done? And I already said
90
00:07:33,090 --> 00:07:37,740
that Broadcom uses those vendor-specific
HCI commands. To read them out, they are:
91
00:07:37,740 --> 00:07:42,180
READ_RAM, WRITE_RAM and LAUNCH_RAM, and
they do exactly what you think they would
92
00:07:42,180 --> 00:07:46,560
do. So basically we are able to read and
write in the address space of the
93
00:07:46,560 --> 00:07:50,840
firmware, and also to execute arbitrary
code snippets in the context of the
94
00:07:50,840 --> 00:07:55,530
firmware. And this is pretty powerful.
Broadcom actually uses this to do their
95
00:07:55,530 --> 00:08:01,310
firmware updates, so they ship so-
called HCD files, which are files that
96
00:08:01,310 --> 00:08:05,030
contain firmware updates. If you have a
Broadcom chip inside your laptop or inside
97
00:08:05,030 --> 00:08:08,750
your phone, you should find such a file
with the extension ".hcd" on your
98
00:08:08,750 --> 00:08:13,620
filesystem, and those files actually
contain just a sequence of those commands
99
00:08:13,620 --> 00:08:18,150
to upload all the changes and patches, and
they're even able to do temporary patches
100
00:08:18,150 --> 00:08:23,750
to the ROM of the firmware by another
mechanism that they call "Patchram." We also
101
00:08:23,750 --> 00:08:28,340
had to reverse engineer this and now we
are finally able to do all those patching
102
00:08:28,340 --> 00:08:34,570
ourselves. Now, what is also interesting
is that those files, the .hcd files, are
103
00:08:34,570 --> 00:08:38,890
neither encrypted nor signed. So it's
quite easy to actually modify them once
104
00:08:38,890 --> 00:08:42,839
you understand how they work. And also the
firmware itself on the controller is not
105
00:08:42,839 --> 00:08:47,839
obfuscated. So there are basically no
major attempts done by Broadcom to prevent
106
00:08:47,839 --> 00:08:53,040
anyone to reverse engineer and modify
this firmware. Currently, we write our
107
00:08:53,040 --> 00:08:57,519
code and assembler, so we write assembler
patches, but we're working on including
108
00:08:57,519 --> 00:09:02,720
this in our NexMon project to finally be
able to write patches in C code, which
109
00:09:02,720 --> 00:09:07,860
will be more comfortable and portable.
First of course we have to do the
110
00:09:07,860 --> 00:09:10,860
reversing.
Jiska: Yeah. So as Dennis told you the
111
00:09:10,860 --> 00:09:15,060
code is not obfuscated but there is no
strings and no function names. So you end
112
00:09:15,060 --> 00:09:20,140
up with thousands of functions that just
have no name, it's just sub 1, sub 2, sub
113
00:09:20,140 --> 00:09:25,020
some-thousand something. And then there is
a tool that I used which is called CodeCut
114
00:09:25,020 --> 00:09:32,769
to try to separate those functions into
modules. But also the modules don't really
115
00:09:32,769 --> 00:09:36,250
tell you that much because the problem is:
then you have hundreds of modules and then
116
00:09:36,250 --> 00:09:41,720
you know which modules are central and you
might to start reversing but it's not
117
00:09:41,720 --> 00:09:45,590
really fun. You have 2800 pages of
Bluetooth standards, you might have some
118
00:09:45,590 --> 00:09:51,579
parameter checks in there, so you have
bounds which the parameters should be in,
119
00:09:51,579 --> 00:09:55,860
and then you search for those numbers
again in assembly code and you might find
120
00:09:55,860 --> 00:10:00,500
some matches and then you have concrete
functions. So that's what we both did for
121
00:10:00,500 --> 00:10:08,790
months. staring at standards, staring at
the code. Then people asked me: "Yes,
122
00:10:08,790 --> 00:10:15,019
that's not nice, but does it work on on
recent devices?" And now the problem is
123
00:10:15,019 --> 00:10:20,450
even the Nexus 6P has a firmware from end
of 2014. So I just decided to buy a
124
00:10:20,450 --> 00:10:24,899
development board, which has also a
slightly outdated firmware, I mean just
125
00:10:24,899 --> 00:10:31,300
one year old. Meanwhile, this part of
Broadcom was acquired by Cypress so it's
126
00:10:31,300 --> 00:10:37,250
called Cypress. But it doesn't matter,
it's still the same mechanisms in there.
127
00:10:37,250 --> 00:10:42,040
And I was able to use the same HCI
commands, so I can still modify the
128
00:10:42,040 --> 00:10:48,950
firmware on this, I can extract the
firmware, and actually I just got that on
129
00:10:48,950 --> 00:10:56,050
December 6, and 3 days later I had all
function names because somewhere someone
130
00:10:56,050 --> 00:11:03,539
forgot a patch.elf with all function names
in the development kit. So that's 11 000
131
00:11:03,539 --> 00:11:09,439
function names, 3000 object names. Nice.
Yeah.
132
00:11:09,439 --> 00:11:17,680
Applause
J: So, buy development kits earlier.
133
00:11:17,680 --> 00:11:23,420
Laughter
D: OK. Let's get closer to the first demo.
134
00:11:23,420 --> 00:11:26,589
So as mentioned we have this Link Manager
Protocol which does interesting things
135
00:11:26,589 --> 00:11:30,720
like pairing and all kinds of stuff. And
it's implemented in the firmware so we
136
00:11:30,720 --> 00:11:34,599
cannot really see it from outside, we
cannot capture it in Wireshark. And we
137
00:11:34,599 --> 00:11:37,990
wanted to change that. So we wrote a patch
that will actually hook some of the
138
00:11:37,990 --> 00:11:42,699
functions inside the firmware, those that
are handling LMP, to actually forward all
139
00:11:42,699 --> 00:11:47,209
the traffic over the HCI interface back to
our Android phone. And then on the Android
140
00:11:47,209 --> 00:11:50,529
phone we use a Android Bluetooth stack
which has debugging features compiled into
141
00:11:50,529 --> 00:11:56,640
it so that we can also forward all the HCI
traffic via TCP to our host computer. And
142
00:11:56,640 --> 00:12:00,350
from there we can then show it in
Wireshark. We use a custom LMP dissector
143
00:12:00,350 --> 00:12:05,129
plugin which we borrowed from the
Ubertooth project. And yeah, that's it. We
144
00:12:05,129 --> 00:12:11,100
have a LMP monitor mode. I will show that
in just a second. We also have an LMP
145
00:12:11,100 --> 00:12:15,959
injection mode, so we can simply invoke
functions inside the firmware. And so we
146
00:12:15,959 --> 00:12:20,410
can also invoke the function which
actually sends LMP packets to other
147
00:12:20,410 --> 00:12:25,490
devices which are connected to our Nexus
5. And so, yeah, with this we have both
148
00:12:25,490 --> 00:12:30,660
channels of the communication and can
actually send arbitrary traffic to other
149
00:12:30,660 --> 00:12:38,790
devices. So, for this let's go into a
command line and start the framework. The
150
00:12:38,790 --> 00:12:43,620
framework has a command line interface we
can use all of its features and interact
151
00:12:43,620 --> 00:12:50,070
with the firmware and to start a monitor
mode, I can just type this command which
152
00:12:50,070 --> 00:12:55,329
will start a Wireshark instance and also
install all the patches which we need into
153
00:12:55,329 --> 00:13:01,079
the firmware of the phone. Now from this
time on, we actually have all LMP traffic
154
00:13:01,079 --> 00:13:06,060
forwarded and shown in the Wireshark
frame, but currently we don't have a
155
00:13:06,060 --> 00:13:17,379
Bluetooth connection, that's why you don't
see anything. Ok. Yeah, so we still need a
156
00:13:17,379 --> 00:13:22,990
Bluetooth connection, right? I could just
pair those devices to create a connection
157
00:13:22,990 --> 00:13:27,680
and then we would see LMP traffic, but I
want to show something else. So this will
158
00:13:27,680 --> 00:13:31,089
be a combined demo actually, because
Bluetooth has some more interesting
159
00:13:31,089 --> 00:13:36,559
features which maybe not everyone knows -
at least for me that was a surprise when I
160
00:13:36,559 --> 00:13:42,309
first learned about this. So even if your
device is not being set to be discoverable
161
00:13:42,309 --> 00:13:46,900
by other devices, it still accepts
connections from any other device, the
162
00:13:46,900 --> 00:13:51,740
other device just needs to know your MAC
address and can simply connect to you,
163
00:13:51,740 --> 00:13:56,240
without even being paired before, you
don't even notice this because the device
164
00:13:56,240 --> 00:13:59,540
does not have to trigger the pairing
process, and then the user won't be
165
00:13:59,540 --> 00:14:03,749
notified. And so by just finding out the
MAC address of any other device I can
166
00:14:03,749 --> 00:14:09,160
connect to it on this LMP layer and start
communicating with it. And finding out the
167
00:14:09,160 --> 00:14:13,240
MAC address is also not that hard. There
was another talk which we mention down on
168
00:14:13,240 --> 00:14:17,009
the bottom of the slide, it's called
"Bluetooth smells like chicken" by Dominik
169
00:14:17,009 --> 00:14:20,809
Spill, Michael Ossmann and Mark Steward,
which shows that this is actually possible
170
00:14:20,809 --> 00:14:28,430
and not hard to do. So, I can actually
just type "connect" and give it the MAC
171
00:14:28,430 --> 00:14:33,570
address of another phone.
J: We need again... ah great.
172
00:14:33,570 --> 00:14:37,829
D: Yes. Perfect! On the right side you
actually see a Nexus 6P, which will be our
173
00:14:37,829 --> 00:14:44,189
target. You can hopefully barely read the
MAC address which is shown there on the
174
00:14:44,189 --> 00:14:48,430
left side as the Nexus 5 which is the
phone we use for for testing like the
175
00:14:48,430 --> 00:14:54,920
phone which is connected to my laptop here
and is used for InternalBlue. And as you
176
00:14:54,920 --> 00:14:58,789
also can see the Nexus 6P is currently not
in the Bluetooth menu, so it's not
177
00:14:58,789 --> 00:15:04,920
actually discoverable by by means of
Bluetooth. I still can connect to it when
178
00:15:04,920 --> 00:15:10,879
I actually type "connect" and the MAC
address this might may take a few ... no
179
00:15:10,879 --> 00:15:16,110
it worked directly, perfect. So now we can
see that we actually have traffic on the
180
00:15:16,110 --> 00:15:20,279
LMP layer. What you also might notice that
that on the Nexus 6P there wasn't
181
00:15:20,279 --> 00:15:23,800
anything. So the user didn't notice, but I
have an established connection to this
182
00:15:23,800 --> 00:15:28,620
other phone and you can see the LMP
traffic which is going on on this protocol
183
00:15:28,620 --> 00:15:33,370
layer. As you can see it is quite a lot:
There are feature requests, version
184
00:15:33,370 --> 00:15:39,519
requests, also name requests so that the
phones know how the name of each other is.
185
00:15:39,519 --> 00:15:44,269
And yeah, from now on I can also try to
inject arbitrary LMP packets. For
186
00:15:44,269 --> 00:15:49,379
example I can send an LMP packet with code
"01" which would be a name request and ask
187
00:15:49,379 --> 00:15:55,259
for a name at offset 0. And you should see
that the name request has popped up here
188
00:15:55,259 --> 00:16:01,290
and the other device even answered with
its name. If you scroll down here should
189
00:16:01,290 --> 00:16:07,559
at some point see that we have the name
"Nexus 6P" because we don't renamed our
190
00:16:07,559 --> 00:16:11,619
devices. But I can also send
arbitrary LMP packets so I'm not bound to
191
00:16:11,619 --> 00:16:15,089
anything that is in the specification.
J: You already got the detach!
192
00:16:15,089 --> 00:16:20,339
D: So the other device actually detached
which happens from time to time ... can
193
00:16:20,339 --> 00:16:22,339
reconnect.
J: If we don't do anything in between we
194
00:16:22,339 --> 00:16:26,990
will get a detach from the other device
because we didn't do a paring or something
195
00:16:26,990 --> 00:16:31,879
so we re-established connection. And now
Dennis is going to send something that is
196
00:16:31,879 --> 00:16:36,400
not specified ... just an LMP 99.
D: So it's even saying here this is
197
00:16:36,400 --> 00:16:40,480
unknown. But as you can see the payload is
actually sent and the other device
198
00:16:40,480 --> 00:16:45,470
correctly answers with "this is not
accepted and I don't want this". But you
199
00:16:45,470 --> 00:16:48,670
can probably see that this is very
interesting for a security researcher,
200
00:16:48,670 --> 00:16:52,480
because now he can see how the other
device happens in certain conditions, if
201
00:16:52,480 --> 00:16:57,760
you send them certain packets. Yeah. Quite
nice to actually experiment with. OK. I
202
00:16:57,760 --> 00:17:02,879
think that's it for the first demo. Let's
stop this and go back to this.
203
00:17:02,879 --> 00:17:06,590
J: I don't need the in-screen anymore.
Yeah. Great. Okay.
204
00:17:06,590 --> 00:17:14,760
Applause
D: Thank you.
205
00:17:14,760 --> 00:17:17,940
J: Another thing in the Bluetooth standard
is that you need a possibility to pair
206
00:17:17,940 --> 00:17:23,380
devices, which have no input and no output
capability, so they cannot show a PIN and
207
00:17:23,380 --> 00:17:29,890
you cannot enter a PIN. And this is the
standard for any headset. But also a Man-
208
00:17:29,890 --> 00:17:35,670
in-the-Middle can change the input/output
capabilities and then you might just get
209
00:17:35,670 --> 00:17:41,480
displayed this "yes/no" pairing without a
PIN request. Even though your smartphone
210
00:17:41,480 --> 00:17:48,580
could show more than this. And I have a
demo video again of the same thing. That's
211
00:17:48,580 --> 00:17:53,000
this one. So on the left hand side I have
again a Nexus 5 on the right hand side I
212
00:17:53,000 --> 00:17:59,680
have an iPhone and I am pairing them. I
just changed the request and the
213
00:17:59,680 --> 00:18:04,030
capabilities that it's, that I'm not having
input output capability. So you can see on
214
00:18:04,030 --> 00:18:09,180
the right hand side on the iPhone it's
just showing this "yes/no" question. And
215
00:18:09,180 --> 00:18:12,560
on the left hand side you still have the
same algorithm which just does the same
216
00:18:12,560 --> 00:18:21,460
thing. So pairing will succeed, there's
the same cryptographic routines but you
217
00:18:21,460 --> 00:18:24,750
are not being warned on the iPhone and
that's a bit critical. So the standard is
218
00:18:24,750 --> 00:18:30,150
not saying: "Please warn the user to check
if the other phone really has no input
219
00:18:30,150 --> 00:18:34,912
output." So I just say pair and it pairs.
220
00:18:38,051 --> 00:18:45,180
Yup.
Applause
221
00:18:46,260 --> 00:18:49,432
So far that's only things that are as
222
00:18:49,432 --> 00:18:55,741
they are in the standard, so it's not too
surprising. So the question is: Can we
223
00:18:55,741 --> 00:19:02,550
find more bugs? Yeah. Finding bugs in
Bluetooth. Actually I didn't even want to
224
00:19:02,550 --> 00:19:06,170
find bugs in the beginning, I just wanted
to understand how everything works. So I
225
00:19:06,170 --> 00:19:11,860
went through the handlers and I checked
the... there's these checks of the
226
00:19:11,860 --> 00:19:15,810
parameters, so there is a parameter check
in the beginning of each handler that
227
00:19:15,810 --> 00:19:21,330
shows me a bit which handler it could be
according to the standard. And suddenly
228
00:19:21,330 --> 00:19:26,130
there is a handler which does not have any
check. So there's just the missing "if"
229
00:19:26,130 --> 00:19:30,960
somewhere. And then I compared to firmware
versions that I had and found out they
230
00:19:30,960 --> 00:19:39,540
silently patched that already some time
between June 2nd and August 19th in 2014.
231
00:19:39,540 --> 00:19:44,960
But they never updated older devices, so
they never shipped an .hcd-patch. So I
232
00:19:44,960 --> 00:19:48,860
contacted Broadcom and said: "Yeah you
have a problem!" and they said "No, we
233
00:19:48,860 --> 00:19:53,320
don't." And I said: "You really have a
problem there." And so on... And then they
234
00:19:53,320 --> 00:19:58,270
said: "It doesn't exist." And then I
showed them more and then they said "Yeah
235
00:19:58,270 --> 00:20:01,900
ok, but it's not compliant to the standard
what you're doing!"
236
00:20:01,929 --> 00:20:08,515
Laughter
Applause
237
00:20:08,515 --> 00:20:11,650
I'm sorry, my next exploit will be
standard complaint.
238
00:20:11,650 --> 00:20:14,780
Laughter
And then we discussed a bit more and then
239
00:20:14,780 --> 00:20:18,000
they said: "It does not affect Wi-Fi
performance." Well, in my tests it did...
240
00:20:18,000 --> 00:20:23,680
whatever... doesn't matter. So basically
you can switch off Bluetooth on another
241
00:20:23,680 --> 00:20:29,590
device and then Bluetooth restarts
typically depending on configuration. And
242
00:20:29,590 --> 00:20:34,350
as Broadcom didn't tell me much about this
I started testing out things on my own. So
243
00:20:34,350 --> 00:20:38,130
which devices actually still have a
firmware that is affected in their
244
00:20:38,130 --> 00:20:46,540
Broadcom chip? It's quite a lot. So it's
like the iPhone 6, MacBook Pro from 2016,
245
00:20:46,540 --> 00:20:51,270
of course my Nexus 5, Raspberry Pi 3 and
so on. And this list is really not
246
00:20:51,270 --> 00:20:55,640
complete this is just like, I asked my
students: "Can I test your smartphone?"
247
00:20:55,640 --> 00:20:59,700
Some of them said: "No. Are you crazy?!"
Laughter
248
00:20:59,700 --> 00:21:06,590
And that's the list I got just during the
last weeks. And this is the one I'm going
249
00:21:06,590 --> 00:21:12,680
to demo. I just named it BT-B-g0ne, so you
can kill the Bluetooth of annoying songs
250
00:21:12,680 --> 00:21:22,620
or something.
Applause
251
00:21:22,620 --> 00:21:33,730
So I need to go into the Bluetooth here,
yeah, screen-in-screen... That's great. I
252
00:21:33,730 --> 00:21:38,000
even had a "Bluetooth is not real" and so
on. That's really great. What is going on
253
00:21:38,000 --> 00:21:39,430
here.
D: OK.
254
00:21:39,430 --> 00:21:44,420
J: Yeah let's go for the demo. So first we
are going to patch the Nexus 5 with our
255
00:21:44,420 --> 00:21:50,550
funny attack and then just press enter and
now it takes a while until the the iPhone
256
00:21:50,550 --> 00:21:54,790
is realizing like "Oops my Bluetooth is
gone." So if I'm playing music you will
257
00:21:54,790 --> 00:21:58,530
see it faster, the music would already
stop playing. Let me just enter another
258
00:21:58,530 --> 00:22:01,949
time. Just... Yes, and there it's gone!
Oops!
259
00:22:01,949 --> 00:22:08,920
Applause
260
00:22:08,924 --> 00:22:10,974
And then it appears again and so on I can
261
00:22:10,974 --> 00:22:14,940
just do it again and again and again. And
it's actually so fast that the other
262
00:22:14,940 --> 00:22:20,070
person could not play music, because music
also stops playing after this disconnect.
263
00:22:20,070 --> 00:22:25,440
Yeah that's the demo. Now we were
wondering, yeah, what is actually
264
00:22:25,440 --> 00:22:31,490
happening. So actually that the crash -
the crash is the best case. So there is a
265
00:22:31,490 --> 00:22:37,380
handler. I call it "Handler A", because
I'm not leaking the actual problem here.
266
00:22:37,380 --> 00:22:43,180
Broadcom didn't fix it yet. So there is
this handler which just should take, let's
267
00:22:43,180 --> 00:22:50,110
say, two arguments or something. But it
doesn't check the parameter range and the
268
00:22:50,110 --> 00:22:55,830
compiler likes to put one handler after
the other. And then we just go into the
269
00:22:55,830 --> 00:23:01,530
next handler, and so we have something
like 250 functions that we can call from
270
00:23:01,530 --> 00:23:06,540
the next handler but with wrong
parameters. So it's a bit buggy, and
271
00:23:06,540 --> 00:23:12,990
sometimes if a function expects to get
other parameters it just crashes. But
272
00:23:12,990 --> 00:23:18,500
otherwise we can execute functions. And on
the Nexus 5 we looked a bit more into this
273
00:23:18,500 --> 00:23:23,790
and I found out that I can enable test
mode. So test mode should be something
274
00:23:23,790 --> 00:23:28,640
only locally to be enabled on a phone if
you have root access to the driver and
275
00:23:28,640 --> 00:23:32,450
then you tell the driver: "I'm now going
to test your frequencies and so on please
276
00:23:32,450 --> 00:23:35,529
go in test mode." But I can now do this
remotely.
277
00:23:37,010 --> 00:23:42,996
Applause
278
00:23:43,230 --> 00:23:45,220
So I didn't bring this one as a live demo.
279
00:23:45,220 --> 00:23:49,358
I mean I have a HackRF with me, we can do
that during Q and A, because the problem
280
00:23:49,358 --> 00:23:52,910
is there is probably too much going on in
the spectrum here and you wouldn't see the
281
00:23:52,910 --> 00:24:01,150
test mode starting anyway. So I'm just
doing the attack and then on the left hand
282
00:24:01,150 --> 00:24:04,330
side, I just took a quick pause, you can
see the test mode, so that's just the
283
00:24:04,330 --> 00:24:09,690
default test mode hopping around in all
channels. The packets now appear a bit out
284
00:24:09,690 --> 00:24:15,170
of order because I just put them into a
queue, send them. This "???" payload is
285
00:24:15,170 --> 00:24:19,910
the malicious payload. I just send
"test_control" and "test_activate". And
286
00:24:19,910 --> 00:24:28,120
first they get this not_accepted. And then
after this "???" payload you can see that
287
00:24:28,120 --> 00:24:32,510
it's accepted. And on the left hand side
you can still see that there is the test
288
00:24:32,510 --> 00:24:39,977
mode going on, so really block things for
longer time. And then it's accepted, magic!
289
00:24:42,448 --> 00:24:48,648
Applause
290
00:24:48,860 --> 00:24:52,330
If you combine this with disabling
adaptive frequency hopping you can even
291
00:24:52,330 --> 00:24:58,080
force the other device, which is also then
in test mode, to stop hopping for a while
292
00:24:58,080 --> 00:25:02,880
and then just jam a selected frequency, so
you could also jam a selected Wi-Fi
293
00:25:02,880 --> 00:25:07,750
frequency that this device is currently
using. And it's a combo chip, so you would
294
00:25:07,750 --> 00:25:13,360
really be on the same antenna. We can
confirm this works on Nexus 5 and Xperia
295
00:25:13,360 --> 00:25:18,950
Z3, because they both have to be same
BCM4339 chip. It might also work on other
296
00:25:18,950 --> 00:25:24,630
devices with that chip. It's a bit random
to find out what is in there. You need to
297
00:25:24,630 --> 00:25:31,740
find teardowns and on. So when finding
this bug we started developing a
298
00:25:31,740 --> 00:25:37,720
toolchain. So Dennis added a feature for
tracepoints. You can add now a tracepoint
299
00:25:37,720 --> 00:25:41,410
to a function which is then called once
and dumps all the registers and the stack
300
00:25:41,410 --> 00:25:47,650
and heap. I then fed this into an
emulation framework, which is currently
301
00:25:47,650 --> 00:25:52,510
quite slow with unicorn and radare2,
but I get a full call trace, which is very
302
00:25:52,510 --> 00:25:56,960
nice to look at. So I have an idea what is
going on, what is changed in the memory.
303
00:25:56,960 --> 00:26:01,171
And I currently have a student working on
a qemu/gdb set up, which is faster but
304
00:26:01,171 --> 00:26:06,870
producing less output, just to fuzz more
efficiently. However, you get really a lot
305
00:26:06,870 --> 00:26:11,060
of output that we weren't able to
completely analyze yet, so there's
306
00:26:11,060 --> 00:26:19,580
probably more. Maybe tell you somewhen
later. Now you need to somehow fix that
307
00:26:19,580 --> 00:26:23,050
bug. And that's that's really a problem,
and that's also why I didn't tell you the
308
00:26:23,050 --> 00:26:29,200
exact payload that is causing these
issues. Because, well, the fix would be in
309
00:26:29,200 --> 00:26:33,880
one of those .hcd-files. It would be
plaintext. It would not be signed and it
310
00:26:33,880 --> 00:26:38,750
would just tell you directly "This handler
is vulnerable in exactly this position!"
311
00:26:38,750 --> 00:26:44,080
and so on. The patch is just 14 bytes, but
you need to install it and then it's easy
312
00:26:44,080 --> 00:26:48,720
to understand what it does, right? So I
had an idea: Let's do some more generic
313
00:26:48,720 --> 00:26:54,390
fix. So what I planned to do was having a
generic filter, filtering some packets
314
00:26:54,390 --> 00:26:58,270
like that you won't reply to, pings
connection establishments and so on, to
315
00:26:58,270 --> 00:27:04,800
untrusted devices. And then just over
Christmas I started testing that one with
316
00:27:04,800 --> 00:27:10,650
bigger setups, with more phones and so on.
And then I realized: OK if I throw away
317
00:27:10,650 --> 00:27:16,210
some packets and the other device does not
expect me to throw away packets, then the
318
00:27:16,210 --> 00:27:23,130
Bluetooth stack of a device which now
tries to connect to me is going to crash.
319
00:27:23,130 --> 00:27:26,730
So I had the next bug! So I tried to fix
one bug. I get the next bug, you know
320
00:27:26,730 --> 00:27:34,650
this. So I actually cannot release any
fix, because ... uh. Yeah. Because all of
321
00:27:34,650 --> 00:27:43,710
them still cause the next bug and so on.
So how long will this bug be around?
322
00:27:43,710 --> 00:27:47,900
Pretty long probably because there is some
devices which are no longer getting vendor
323
00:27:47,900 --> 00:27:53,000
updates. It needs to be in the vendor
update, it needs to be this special .hcd-
324
00:27:53,000 --> 00:27:59,960
file. And so on. I mean we can also
publish .hcd-files if needed. That's
325
00:27:59,960 --> 00:28:04,100
possible with our framework. That's the good
news, but it will probably never be an
326
00:28:04,100 --> 00:28:09,070
official update. And the vendor updates
will obviously leak the vulnerability. So
327
00:28:09,070 --> 00:28:15,790
it's chicken-egg. As we found this bug
still to be present in devices that were
328
00:28:15,790 --> 00:28:21,610
produced in 2016, we recommend you to turn
off Bluetooth - especially if you have a
329
00:28:21,610 --> 00:28:29,430
Broadcom chipset produced before 2017.
But in general just turn it off. That's
330
00:28:29,430 --> 00:28:34,720
probably the safest option. And we found
out that very old devices having something
331
00:28:34,720 --> 00:28:40,420
like Bluetooth 3.0 are not vulnerable,
because that feature that we used didn't
332
00:28:40,420 --> 00:28:46,744
exist back then. But still it's a large
number of devices having this issue.
333
00:28:48,796 --> 00:28:50,680
So, thanks for listening.
334
00:28:50,682 --> 00:29:02,660
Long Applause
335
00:29:03,140 --> 00:29:09,270
Herald: And again if you have questions we
have 8 microphones in the hall. Please
336
00:29:09,270 --> 00:29:12,767
line up at the microphones and you can ask
your questions.
337
00:29:15,539 --> 00:29:18,608
The Signal Angel has the first
question from the Internet.
338
00:29:18,637 --> 00:29:22,973
Signal Angel: Yes some of the Internet
asked if you can guess the Bluetooth MAC
339
00:29:22,990 --> 00:29:30,500
address from the wifi MAC address of a device.
Jiska: Yes. So if I go into... Can we
340
00:29:30,500 --> 00:29:38,800
switch the camera on again? On my magic
box here. Is that possible? Yes. So
341
00:29:38,800 --> 00:29:49,840
actually, if you go to the "Settings",
"About", and then you will see that the
342
00:29:49,840 --> 00:29:53,130
WiFi and Bluetooth MAC address, they are
just off by one.
343
00:29:53,130 --> 00:30:02,260
Laughter and applause
Dennis: So yeah. You have to note however
344
00:30:02,260 --> 00:30:06,640
that this is not the case with every
phone. So usually I think new phones
345
00:30:06,640 --> 00:30:13,090
actually try to randomize their Wi-Fi MAC
address to be not traceable anymore. Not
346
00:30:13,090 --> 00:30:18,670
sure which devices do that. I think the
Nexus 6P does that so the first part will
347
00:30:18,670 --> 00:30:24,040
be the same, because it specifies which
vendor this chip was made from. But then,
348
00:30:24,040 --> 00:30:28,590
the lower and least significant bits will
change. So it's sometimes possible,
349
00:30:28,590 --> 00:30:32,890
sometimes not. Yeah. I think that's the
answer to this question.
350
00:30:32,890 --> 00:30:38,300
Herald: OK. The next question was from the
microphone 8 at the very end of the hall.
351
00:30:38,726 --> 00:30:41,929
Eight: Hello. Thanks for your talk. I was
352
00:30:41,929 --> 00:30:47,160
wondering in your second demo, you showed
us how you connect to a device, just using
353
00:30:47,160 --> 00:30:53,320
the MAC address and this device was not
advertising his name. How do you find a
354
00:30:53,320 --> 00:30:58,640
MAC address, if it's not advertising?
Dennis: Yeah. So there are ways to find
355
00:30:58,640 --> 00:31:04,750
out the MAC address of devices which are
nearby you. So for example if your device
356
00:31:04,750 --> 00:31:07,880
has Bluetooth turned on but it's not
discoverable at the moment, but you're
357
00:31:07,880 --> 00:31:12,060
listening to music on your headphones or
if you have a smartwatch connected or
358
00:31:12,060 --> 00:31:16,290
any other Bluetooth device connected, then
you will certainly send Bluetooth traffic
359
00:31:16,290 --> 00:31:19,940
and you can sniff that from the air. For
example with a software-defined radio or
360
00:31:19,940 --> 00:31:26,310
an Ubertooth. And so in the talk we
mentioned and we also have a link to this
361
00:31:26,310 --> 00:31:30,420
in the slide, I guess it was here,
"Bluetooth smells like chicken". Michael
362
00:31:30,420 --> 00:31:35,460
Ossman and Dominic Spill, they actually
explained very detailed how you can then
363
00:31:35,460 --> 00:31:40,290
infer the MAC address from those packets
you sniffed. And, yeah, it's doable. It's
364
00:31:40,290 --> 00:31:42,940
not as easy as with Wi-Fi but it's
certainly possible.
365
00:31:42,940 --> 00:31:45,900
Eight: Thank you.
Herald: Okay. The next question was at
366
00:31:45,900 --> 00:31:50,360
Microphone number one.
One: Thanks for your talk and demos. The
367
00:31:50,360 --> 00:31:59,580
question is, does this firmware have any
mitigations against exploitation? And if
368
00:31:59,580 --> 00:32:03,000
we imagine that it has, would it help
against such bugs?
369
00:32:03,000 --> 00:32:10,630
Dennis: So. There's no, like real address
randomization, kind of the obvious way,
370
00:32:10,630 --> 00:32:14,930
because there's... Most of the things are
actually global offsets inside the
371
00:32:14,930 --> 00:32:18,130
firmware. So everything is at fixed
addresses, like you would use global
372
00:32:18,130 --> 00:32:25,180
variables all over. There's also the RAM,
it's actually executable, so you can
373
00:32:25,180 --> 00:32:29,120
execute on the stack, you can execute on
the heap, everywhere. So there's no real
374
00:32:29,120 --> 00:32:34,550
mitigations for such a exploitation. It's
like, I don't think even the newer ones
375
00:32:34,550 --> 00:32:36,840
have that sort of, and the Nexus 5
obviously.
376
00:32:36,840 --> 00:32:41,800
Jiska: And another thing that really helps
us. So LMP has a version_request,
377
00:32:41,800 --> 00:32:46,580
version_response, which is always sent. So
I can ask a device actually: Do you have a
378
00:32:46,580 --> 00:32:51,560
vulnerable firmware and which version? And
then I can run exactly the exploit. And
379
00:32:51,560 --> 00:32:55,550
the firmware, I mean, the firmware is
standard and I can just run the addresses
380
00:32:55,550 --> 00:33:01,470
that I know for a certain firmware.
Herald: Okay. The next question was at
381
00:33:01,470 --> 00:33:05,630
microphone number two. Then again number
one, three and five.
382
00:33:05,630 --> 00:33:10,680
Two: Hi. Thanks for the work especially
for BT-B-g0ne since like it's the TV-B-
383
00:33:10,680 --> 00:33:17,270
Gone. And I'm not sure of which kind of
iPhone that works, because you had a slide
384
00:33:17,270 --> 00:33:22,230
about iPhone up until 6, and then you had
a slide that saying if the chip is older
385
00:33:22,230 --> 00:33:26,480
than 2017. So does that work with the last
phones as well?
386
00:33:26,480 --> 00:33:30,160
Jiska: Only up to iPhone 6 that was used
was the latest I could get. So if you have
387
00:33:30,160 --> 00:33:34,180
an iPhone 8 or something, our attack does
not work.
388
00:33:34,180 --> 00:33:38,580
Two: So you're going to work on it?
Because a lot of people are playing very
389
00:33:38,580 --> 00:33:42,460
bad music and have new phones.
Laughter
390
00:33:42,460 --> 00:33:48,070
Jiska: You mean the attack. The attack is
not working on iPhone 6, but the general
391
00:33:48,070 --> 00:33:53,340
framework like patching .hcd-files or
changing the firmware will obviously work
392
00:33:53,340 --> 00:33:55,910
on any Broadcom chip.
Two: Okay, thanks.
393
00:33:55,910 --> 00:33:58,980
Dennis: Broadcom actually uses this
mechanism for all their chips, all their
394
00:33:58,980 --> 00:34:03,861
Bluetooth chips, so you can use this
framework for every Broadcom chip, every
395
00:34:03,861 --> 00:34:07,650
device that has a Broadcom chip. You only
need to do the reverse engineering, as to
396
00:34:07,650 --> 00:34:12,168
get like the real addresses and offsets
inside the firmware to do meaningful
397
00:34:12,168 --> 00:34:14,489
patches.
Jiska: But for this you always need to be,
398
00:34:14,489 --> 00:34:18,659
to have a rooted device. You need root
access on the device to run our patching
399
00:34:18,659 --> 00:34:20,819
framework.
Two: Okay. Thanks.
400
00:34:20,819 --> 00:34:23,659
Herald: Okay. Now the question at
microphone number one.
401
00:34:23,659 --> 00:34:28,418
One: Do you have a list of vulnerable
chipsets? So I can check if my phone is
402
00:34:28,418 --> 00:34:31,819
vulnerable if it's not like in those
slides.
403
00:34:31,819 --> 00:34:36,619
Jiska: Yeah, but it's very incomplete. So
I also have that, the version numbers and
404
00:34:36,619 --> 00:34:42,309
subversion numbers of those phones. But
just consider the time range. So if your
405
00:34:42,309 --> 00:34:47,739
smartphone does Bluetooth 4.0 to 4.2 and
it has a Broadcom chip then it's very
406
00:34:47,739 --> 00:34:52,789
likely to be vulnerable.
Herald: Okay, now the question from
407
00:34:52,789 --> 00:34:58,750
microphone number three.
Three: Thank you for the codes and the
408
00:34:58,750 --> 00:35:06,220
talk. Quick question, so have you looked
at a car Bluetooth? And if not, are you
409
00:35:06,220 --> 00:35:12,639
thinking about it?
Dennis: So I actually used this tool. As I
410
00:35:12,639 --> 00:35:17,520
mentioned previously, we are also able to
test other vulnerabilities, for example
411
00:35:17,520 --> 00:35:23,349
this fixed coordinate invalid curve
attack. And so I used my tool to actually
412
00:35:23,349 --> 00:35:27,359
check if a car radio was vulnerable to
this fixed coordinate invalid curve attack
413
00:35:27,359 --> 00:35:31,440
that was released this summer. So it's
basically patched since half a year but
414
00:35:31,440 --> 00:35:37,030
the car was still vulnerable to this. So
the framework is basically usable to test
415
00:35:37,030 --> 00:35:41,440
car radios as well, but I haven't like
specifically looked into a car radio.
416
00:35:41,440 --> 00:35:45,130
Three: Thank you.
Herald: Okay. Now a question from
417
00:35:45,130 --> 00:35:49,230
Microphone number five. Then we take a
question from the Internet and microphone
418
00:35:49,230 --> 00:35:55,990
number six.
Five: What is the attack surface exposed
419
00:35:55,990 --> 00:36:02,779
by your exploits? What's the worst case?
Could you manipulate memory or something?
420
00:36:02,779 --> 00:36:07,270
Jiska: Worst case it's hard to estimate. I
mean we can change some memory addresses
421
00:36:07,270 --> 00:36:12,190
at least in the Nexus 5. And for each
smartphone there are other functions by
422
00:36:12,190 --> 00:36:16,770
the compiler put there. So to really know
what is happening, we would now need to
423
00:36:16,770 --> 00:36:22,890
analyze like really tons of firmwares and
check what is in there and do some
424
00:36:22,890 --> 00:36:28,749
fuzzing. We already found out that some
things only happen if you combine multiple
425
00:36:28,749 --> 00:36:32,320
packets and so on. So it's really hard to
estimate what is the worst case. So the
426
00:36:32,320 --> 00:36:36,920
very worst case would be, so to say, that
you can run arbitrary code in the
427
00:36:36,920 --> 00:36:43,430
Bluetooth, in the Bluetooth firmware
itself, and then the next worst case would
428
00:36:43,430 --> 00:36:47,660
be if there would be another vulnerability
in the driver, that you could escape
429
00:36:47,660 --> 00:36:52,660
the firmware. So that would be the next
step. But that really requires an exploit
430
00:36:52,660 --> 00:36:58,369
chain. So the very worst case would be
something similar. So there has been
431
00:36:58,369 --> 00:37:03,970
vulnerabilities in the Wi-Fi part of
Broadcom chips where you had the
432
00:37:03,970 --> 00:37:11,540
possibility to really run an exploit chain
which then rooted a device in the end. But
433
00:37:11,540 --> 00:37:14,880
it's hard to estimate if you can do it
with this or not.
434
00:37:14,880 --> 00:37:18,280
Herald: OK. Now the question from the
Internet please.
435
00:37:18,280 --> 00:37:22,940
Internet: Do you know if any older but
still supported devices like old MacBooks
436
00:37:22,940 --> 00:37:28,759
are patched and can you actually detect
this in any way other than a chip crash?
437
00:37:28,759 --> 00:37:38,100
Jiska: Not really, so we can try to not
crash the chip by first checking if it is
438
00:37:38,100 --> 00:37:42,810
sending appropriate answers, but typically
the really only thing to be sure is that
439
00:37:42,810 --> 00:37:48,260
it crashes. So that so far is the only
way, because I mean obviously, if Broadcom
440
00:37:48,260 --> 00:37:52,020
would tell "the following chips are
vulnerable", which they didn't so far,
441
00:37:52,020 --> 00:37:57,430
because that's also to protect themselves
probably, then you could be sure. But yeah
442
00:37:57,430 --> 00:38:01,979
as of now that's the only way to check it.
Herald: Thank you. Now the question from
443
00:38:01,979 --> 00:38:06,200
microphone number six please.
Six: Yeah. Would it be possible to
444
00:38:06,200 --> 00:38:13,120
increase the Bluetooth radio transmission
power by patching the firmware? So that
445
00:38:13,120 --> 00:38:18,209
Bluetooth works across entire
buildings and not only in a single room?
446
00:38:18,209 --> 00:38:23,030
Dennis: Yeah. So the thing is, we are
actually now patching the firmware of the
447
00:38:23,030 --> 00:38:27,069
chip, and the firmware does like all the
the link layer stuff of Bluetooth. The
448
00:38:27,069 --> 00:38:31,480
real physical part is probably done in
another component inside the chip which
449
00:38:31,480 --> 00:38:36,210
may be running another kind of small real-
time firmware and we haven't found that
450
00:38:36,210 --> 00:38:40,079
yet. We are still looking for it because
that must be in there somewhere, like that
451
00:38:40,079 --> 00:38:44,529
Bluetooth modem and maybe we can actually
change the settings for this modem. I
452
00:38:44,529 --> 00:38:48,760
don't think it will be too drastical. But
maybe if you're in different areas of the
453
00:38:48,760 --> 00:38:52,049
world and like your Bluetooth has
different strengths in different areas of
454
00:38:52,049 --> 00:38:56,010
the world, you can maybe manipulate that.
But we haven't found it yet.
455
00:38:56,010 --> 00:38:59,090
Six: OK. Thank you.
Herald: Okay. Next question is coming from
456
00:38:59,090 --> 00:39:03,730
microphone number four.
Four: Does the Bluetooth chipset have
457
00:39:03,730 --> 00:39:08,599
access to system RAM?
Dennis: Sorry I didn't get the last word.
458
00:39:08,599 --> 00:39:09,923
Jiska: The system rights or what do you
mean?
459
00:39:09,923 --> 00:39:13,770
Four: The system RAM, memory.
Dennis: You mean the memory of the main
460
00:39:13,770 --> 00:39:16,499
processor like where Android or iOS is
running on?
461
00:39:16,499 --> 00:39:19,589
Four: Yes.
Dennis: No it's not like as with Wi-Fi
462
00:39:19,589 --> 00:39:23,940
where you have direct memory access. But
Bluetooth, the HCI interface is the only
463
00:39:23,940 --> 00:39:29,569
interface between those two processors.
And this is usually done over either USB
464
00:39:29,569 --> 00:39:36,329
or in the Nexus 5 is actually UART.
Herald: Next question is coming from
465
00:39:36,329 --> 00:39:39,930
microphone number three.
Three: Many thanks for the enlightening
466
00:39:39,930 --> 00:39:43,750
and scary talk. I missed a little bit of
the beginning maybe that question was
467
00:39:43,750 --> 00:39:50,970
inside there. Did you or do you considered
to disclose this vulnerability for example
468
00:39:50,970 --> 00:39:56,369
to BSI (Bundesamt für Sicherheit in der
Informationstechnik)? As I would consider
469
00:39:56,369 --> 00:40:01,930
their obligation to inform general public
like put a note on their website saying:
470
00:40:01,930 --> 00:40:06,900
"Look, if you're running a certain
smartphone you're vulnerable to a certain
471
00:40:06,900 --> 00:40:11,810
attack!" And that would put much more
stress on the vendors to really look into
472
00:40:11,810 --> 00:40:14,124
this.
Jiska: Yeah that sounds like a good
473
00:40:14,124 --> 00:40:22,480
option. So far we're, so we asked Broadcom
when we can publish things and at least
474
00:40:22,480 --> 00:40:26,690
they agreed that it's no problem to
publish it in summer, then it would be
475
00:40:26,690 --> 00:40:31,029
public for everyone. But yeah, BSI would
also be a nice option.
476
00:40:31,939 --> 00:40:33,589
Three: Thank you.
477
00:40:33,589 --> 00:40:36,440
Herald: OK. Is there another question
from the Internet?
478
00:40:37,024 --> 00:40:38,624
…
479
00:40:40,409 --> 00:40:45,699
Please switch on the
microphone for the Internet.
480
00:40:45,699 --> 00:40:50,829
Internet: Hello? Hi. So do you know if any
devices have been patched yet, which have
481
00:40:50,829 --> 00:40:55,229
not been released after 2017, or are there
no rolled out patches?
482
00:40:55,229 --> 00:41:01,430
Jiska: I don't think so. So, it took
Broadcom two months to actually confirm
483
00:41:01,430 --> 00:41:05,700
that there is this vulnerability. So on
December 3rd they said, ooops it really
484
00:41:05,700 --> 00:41:12,279
exists. And then on December 9th, they
were like: "Ooh, do you really plan to do
485
00:41:12,279 --> 00:41:15,430
that talk here?!"
Laughter
486
00:41:15,430 --> 00:41:22,430
And I did the most recent iOS update on
the iPhone 6 that I just showed you. And
487
00:41:22,430 --> 00:41:26,490
this one is still valuable. I think it
takes some time for testing. So I would
488
00:41:26,490 --> 00:41:32,309
say the first patches will come out maybe
in 1, 2 months, but we don't know.
489
00:41:32,309 --> 00:41:35,670
Herald: Okay. One last quick question from
microphone number one.
490
00:41:35,670 --> 00:41:40,180
One: So is it … do you think it is
possible to trace back when was this
491
00:41:40,180 --> 00:41:44,900
vulnerability introduced, so we can go
back and try to hack old devices that
492
00:41:44,900 --> 00:41:49,670
probably have the same firmware or
firmware vulnerability? Because they
493
00:41:49,670 --> 00:41:55,539
should be backward compatible, right? So
if the same handler is implemented I
494
00:41:55,539 --> 00:42:00,130
know in 2012 first and for the first time
then uh...
495
00:42:00,130 --> 00:42:02,510
Jiska: Yeah.
One: Probably the devices can be narrowed
496
00:42:02,520 --> 00:42:04,829
down, right?
Jiska: So at least.. so the Nexus 5 has a
497
00:42:04,829 --> 00:42:14,990
firmware from 2012 actually. So somewhere,
so the June 2nd is when it still existed
498
00:42:14,990 --> 00:42:21,220
in 2014. I don't know. So in each firmware
there is a build date and I would then
499
00:42:21,220 --> 00:42:25,559
need to extract the firmware of vulnerable
devices and so on, so it's a long process,
500
00:42:25,559 --> 00:42:28,690
but at least the vulnerability was there
for multiple years.
501
00:42:30,070 --> 00:42:34,530
Herald: Okay now give please a huge round
of applause for Jiska Classen
502
00:42:34,530 --> 00:42:36,540
and Dennis Mantz for their talk.
503
00:42:36,540 --> 00:42:37,310
Applause
504
00:42:37,310 --> 00:42:39,291
Dennis: Thank you!
Applause
505
00:42:39,291 --> 00:42:45,166
35C3 outro music
506
00:42:45,166 --> 00:43:03,000
subtitles created by c3subtitles.de
in the year 2019. Join, and help us!