0:00:00.000,0:00:18.380
35c3 preroll music
0:00:20.130,0:00:27.630
Herald: So, Dennis, the left speaker,[br]finished his M.Sc. in IT security this
0:00:27.630,0:00:33.180
year. The next talk is based on his master[br]thesis, InternalBlue, which is a Bluetooth
0:00:33.180,0:00:38.700
experimentation framework for which he[br]even received a prize. Jiska, the right
0:00:38.700,0:00:45.229
speaker, or for you left speaker, has been[br]his supervisor during the thesis and she
0:00:45.229,0:00:49.969
loves breaking things. After several talks[br]about wireless security, software-defined
0:00:49.969,0:00:55.199
radio and Fitbits, she is now talking[br]about Bluetooth. Please welcome on stage
0:00:55.199,0:01:00.219
Dennis Mantz and Jiska Classen to their[br]talk "Dissecting Broadcom Bluetooth".
0:01:00.219,0:01:06.941
Applause[br]Dennis: Yeah. Thank you for the
0:01:06.941,0:01:10.740
introduction and welcome you all to our[br]talk. I'm Dennis and as said I choose
0:01:10.740,0:01:16.810
Bluetooth as the topic for my master's[br]thesis and the outcome basically was I
0:01:16.810,0:01:19.990
reverse engineered the firmware of a[br]Bluetooth controller which was
0:01:19.990,0:01:24.039
manufactured by Broadcom, and I built a[br]little experimentation framework around
0:01:24.039,0:01:27.950
it. And today we are not only going to[br]present the framework, but also various
0:01:27.950,0:01:33.130
kinds of use cases around it, and we also[br]brought along some demos. Now, if you
0:01:33.130,0:01:37.409
start such a big reversing project you[br]certainly know that this will not be an
0:01:37.409,0:01:41.659
easy task and also quite time consuming.[br]So you might want to ask: why did we do
0:01:41.659,0:01:48.539
that in the first place? So there are[br]several good reasons. For one, dissecting
0:01:48.539,0:01:53.350
the firmware and exploring it for[br]reverse engineering is really helpful if
0:01:53.350,0:01:56.890
you want to get insights from a security[br]perspective. And this is what I had in
0:01:56.890,0:02:01.250
mind when I first started my thesis. But[br]then secondly and even better, once you're
0:02:01.250,0:02:05.819
able to modify the firmware you can[br]actually leverage this fully featured and
0:02:05.819,0:02:10.270
working Bluetooth implementation to be[br]your very own experimentation platform, where
0:02:10.270,0:02:16.480
you can add new features or can also alter[br]existing behavior, and it almost feels
0:02:16.480,0:02:20.800
like you can add a kind of open source[br]touch to a closed source and proprietary
0:02:20.800,0:02:25.950
platform which I really like about this[br]project. Certainly this requires a certain
0:02:25.950,0:02:31.130
background in many different departments[br]like security, code analysis, wireless
0:02:31.130,0:02:36.510
signals, embedded programming, and also[br]not every researcher has resources and
0:02:36.510,0:02:42.159
time to do such a reverse engineering[br]project, but we think that the outcomes of
0:02:42.159,0:02:46.709
this project are really helpful and[br]beneficial for the security community. So,
0:02:46.709,0:02:50.819
and last but not least we actually really[br]like reverse engineering. So we already
0:02:50.819,0:02:55.129
had great experiences with similar[br]projects in the past. For example, some of
0:02:55.129,0:02:59.090
you might know the NexMon project, where[br]we reverse engineered and also modified
0:02:59.090,0:03:05.960
the firmware of a Wi-Fi controller. Okay,[br]before we show our work, we first have to
0:03:05.960,0:03:09.879
introduce a few Bluetooth protocols which[br]we will be mentioning quite a lot
0:03:09.879,0:03:15.390
throughout this talk. So the first one[br]would be the host controller interface.
0:03:15.390,0:03:20.390
Some of you might know that, it's the HCI,[br]and it's a protocol layer between the
0:03:20.390,0:03:25.030
Bluetooth controller and the host system,[br]where the health system would be for
0:03:25.030,0:03:29.930
example an Android phone, or iOS, or[br]Linux, or any other operating system which
0:03:29.930,0:03:34.310
implements those upper layers of the[br]Bluetooth protocol stack, and all the
0:03:34.310,0:03:38.429
lower layers are actually implemented[br]inside the Bluetooth controller. And one
0:03:38.429,0:03:43.549
of them would be for example the Link[br]Manager Protocol, the LMP. And this one is
0:03:43.549,0:03:48.240
also really interesting. It actually[br]manages connections to other remote
0:03:48.240,0:03:54.870
Bluetooth devices. For example, pairing is[br]also done on this protocol layer. And
0:03:54.870,0:03:58.760
what's an interesting difference is that[br]the Link Manager Protocol is actually
0:03:58.760,0:04:03.540
transmitted over the air to communicate[br]with other devices, whereas the HCI
0:04:03.540,0:04:07.709
protocol is only used locally to[br]communicate between the operating system
0:04:07.709,0:04:14.180
and the Bluetooth controller. And another[br]interesting fact to know is that the HCI
0:04:14.180,0:04:20.269
is actually able to be observable from the[br]host site. So if you maybe tried to capture
0:04:20.269,0:04:24.420
on a Bluetooth interface in Linux before,[br]or if you turned on the BT snoop log
0:04:24.420,0:04:28.880
feature under the development settings in[br]Android, you probably have seen HCI packets
0:04:28.880,0:04:33.530
in Wireshark before, because this is an[br]easy task to do. However you probably did
0:04:33.530,0:04:37.750
not see LMP packets in Wireshark before,[br]because this protocol layer is actually
0:04:37.750,0:04:41.910
implemented inside the controller and it's[br]not observable from the host side. You
0:04:41.910,0:04:45.100
won't see those packets if you just[br]capture on a Bluetooth interface because
0:04:45.100,0:04:50.710
you can only see what's above the HCI[br]layer. And so the other thing is that you
0:04:50.710,0:04:55.310
cannot also simply sniff this from the air[br]because Bluetooth has frequency hopping
0:04:55.310,0:04:59.920
and encryption. So it's a lot harder to[br]sniff those packets from the air just as
0:04:59.920,0:05:06.890
with Wi-Fi for example. But today we try[br]to change that. Now I will introduce the
0:05:06.890,0:05:10.330
framework I developed and show its[br]features, and later we go into more
0:05:10.330,0:05:16.770
details and also present some demos. As[br]already mentioned, we named the framework
0:05:16.770,0:05:21.790
InternalBlue. It's open source and you can[br]find it on GitHub and currently it's only
0:05:21.790,0:05:26.200
compatible with the Nexus 5 if you want to[br]use all of its features, but we are also
0:05:26.200,0:05:30.250
working to port it to other Bluetooth[br]chips in other smartphones, and also other
0:05:30.250,0:05:35.990
platforms like the Raspberry Pi, and yeah,[br]soon you will have more devices which are
0:05:35.990,0:05:39.940
supported by this framework. We also[br]already gave a talk where we introduced
0:05:39.940,0:05:44.010
the framework and give some details about[br]the internals and how it works. So if
0:05:44.010,0:05:47.110
you're interested and want to learn more[br]then you should check out our previous
0:05:47.110,0:05:50.710
talk which was also recorded and you can[br]find a link down at the bottom of the
0:05:50.710,0:05:56.910
slide as well. Basically in a nutshell we[br]use vendor specific HCI commands which are
0:05:56.910,0:06:01.900
implemented by Broadcom and allow us to[br]read out and modify the firmware while the
0:06:01.900,0:06:06.580
chip is actually running. And on top of[br]this, we basically implemented a Python
0:06:06.580,0:06:11.870
API to interact with the firmware, and we[br]use this API to then implement all kinds
0:06:11.870,0:06:16.680
of features which we find interesting. For[br]example one of the first things we did was
0:06:16.680,0:06:22.590
implementing such a LMP monitoring mode so[br]that we can finally see LMP traffic on our
0:06:22.590,0:06:27.490
laptop in Wireshark. And what comes along[br]with this is that we are also able to
0:06:27.490,0:06:32.610
inject arbitrary LMP packets inside[br]existing Bluetooth connections. And this
0:06:32.610,0:06:36.340
turned out to be also very interesting[br]because then we can test how other devices
0:06:36.340,0:06:40.770
react to maybe packets they don't accept[br]or yeah, at least it's very good for
0:06:40.770,0:06:45.400
experimentation and for example we use[br]this to write a little proof of concept
0:06:45.400,0:06:50.280
script for the fixed coordinate invalid[br]curve attack that was released this
0:06:50.280,0:06:54.020
summer, not by us but by other[br]researchers, and we were able to actually
0:06:54.020,0:06:59.190
prove that other devices are vulnerable to[br]this attack. So this is a really helpful
0:06:59.190,0:07:06.880
and practical tool. Also, at some point we[br]found a crash our own. So we found back in
0:07:06.880,0:07:12.030
some older Broadcom firmwares which allows[br]us to remotely crash the firmware in some
0:07:12.030,0:07:17.440
of the Broadcom chips, and in some cases[br]we are even able to execute a limited set
0:07:17.440,0:07:21.440
of functions, so this might be even more[br]interesting than just a crash - but more
0:07:21.440,0:07:27.640
on that later. Now if you first start with[br]the main thing about this is, how do we
0:07:27.640,0:07:33.090
actually modify the firmware, How is[br]patching being done? And I already said
0:07:33.090,0:07:37.740
that Broadcom uses those vendor-specific[br]HCI commands. To read them out, they are:
0:07:37.740,0:07:42.180
READ_RAM, WRITE_RAM and LAUNCH_RAM, and[br]they do exactly what you think they would
0:07:42.180,0:07:46.560
do. So basically we are able to read and[br]write in the address space of the
0:07:46.560,0:07:50.840
firmware, and also to execute arbitrary[br]code snippets in the context of the
0:07:50.840,0:07:55.530
firmware. And this is pretty powerful.[br]Broadcom actually uses this to do their
0:07:55.530,0:08:01.310
firmware updates, so they ship so-[br]called HCD files, which are files that
0:08:01.310,0:08:05.030
contain firmware updates. If you have a[br]Broadcom chip inside your laptop or inside
0:08:05.030,0:08:08.750
your phone, you should find such a file[br]with the extension ".hcd" on your
0:08:08.750,0:08:13.620
filesystem, and those files actually[br]contain just a sequence of those commands
0:08:13.620,0:08:18.150
to upload all the changes and patches, and[br]they're even able to do temporary patches
0:08:18.150,0:08:23.750
to the ROM of the firmware by another[br]mechanism that they call "Patchram." We also
0:08:23.750,0:08:28.340
had to reverse engineer this and now we[br]are finally able to do all those patching
0:08:28.340,0:08:34.570
ourselves. Now, what is also interesting[br]is that those files, the .hcd files, are
0:08:34.570,0:08:38.890
neither encrypted nor signed. So it's[br]quite easy to actually modify them once
0:08:38.890,0:08:42.839
you understand how they work. And also the[br]firmware itself on the controller is not
0:08:42.839,0:08:47.839
obfuscated. So there are basically no[br]major attempts done by Broadcom to prevent
0:08:47.839,0:08:53.040
anyone to reverse engineer and modify[br]this firmware. Currently, we write our
0:08:53.040,0:08:57.519
code and assembler, so we write assembler[br]patches, but we're working on including
0:08:57.519,0:09:02.720
this in our NexMon project to finally be[br]able to write patches in C code, which
0:09:02.720,0:09:07.860
will be more comfortable and portable.[br]First of course we have to do the
0:09:07.860,0:09:10.860
reversing.[br]Jiska: Yeah. So as Dennis told you the
0:09:10.860,0:09:15.060
code is not obfuscated but there is no[br]strings and no function names. So you end
0:09:15.060,0:09:20.140
up with thousands of functions that just[br]have no name, it's just sub 1, sub 2, sub
0:09:20.140,0:09:25.020
some-thousand something. And then there is[br]a tool that I used which is called CodeCut
0:09:25.020,0:09:32.769
to try to separate those functions into[br]modules. But also the modules don't really
0:09:32.769,0:09:36.250
tell you that much because the problem is:[br]then you have hundreds of modules and then
0:09:36.250,0:09:41.720
you know which modules are central and you[br]might to start reversing but it's not
0:09:41.720,0:09:45.590
really fun. You have 2800 pages of[br]Bluetooth standards, you might have some
0:09:45.590,0:09:51.579
parameter checks in there, so you have[br]bounds which the parameters should be in,
0:09:51.579,0:09:55.860
and then you search for those numbers[br]again in assembly code and you might find
0:09:55.860,0:10:00.500
some matches and then you have concrete[br]functions. So that's what we both did for
0:10:00.500,0:10:08.790
months. staring at standards, staring at[br]the code. Then people asked me: "Yes,
0:10:08.790,0:10:15.019
that's not nice, but does it work on on[br]recent devices?" And now the problem is
0:10:15.019,0:10:20.450
even the Nexus 6P has a firmware from end[br]of 2014. So I just decided to buy a
0:10:20.450,0:10:24.899
development board, which has also a[br]slightly outdated firmware, I mean just
0:10:24.899,0:10:31.300
one year old. Meanwhile, this part of[br]Broadcom was acquired by Cypress so it's
0:10:31.300,0:10:37.250
called Cypress. But it doesn't matter,[br]it's still the same mechanisms in there.
0:10:37.250,0:10:42.040
And I was able to use the same HCI[br]commands, so I can still modify the
0:10:42.040,0:10:48.950
firmware on this, I can extract the[br]firmware, and actually I just got that on
0:10:48.950,0:10:56.050
December 6, and 3 days later I had all[br]function names because somewhere someone
0:10:56.050,0:11:03.539
forgot a patch.elf with all function names[br]in the development kit. So that's 11 000
0:11:03.539,0:11:09.439
function names, 3000 object names. Nice.[br]Yeah.
0:11:09.439,0:11:17.680
Applause[br]J: So, buy development kits earlier.
0:11:17.680,0:11:23.420
Laughter[br]D: OK. Let's get closer to the first demo.
0:11:23.420,0:11:26.589
So as mentioned we have this Link Manager[br]Protocol which does interesting things
0:11:26.589,0:11:30.720
like pairing and all kinds of stuff. And[br]it's implemented in the firmware so we
0:11:30.720,0:11:34.599
cannot really see it from outside, we[br]cannot capture it in Wireshark. And we
0:11:34.599,0:11:37.990
wanted to change that. So we wrote a patch[br]that will actually hook some of the
0:11:37.990,0:11:42.699
functions inside the firmware, those that[br]are handling LMP, to actually forward all
0:11:42.699,0:11:47.209
the traffic over the HCI interface back to[br]our Android phone. And then on the Android
0:11:47.209,0:11:50.529
phone we use a Android Bluetooth stack[br]which has debugging features compiled into
0:11:50.529,0:11:56.640
it so that we can also forward all the HCI[br]traffic via TCP to our host computer. And
0:11:56.640,0:12:00.350
from there we can then show it in[br]Wireshark. We use a custom LMP dissector
0:12:00.350,0:12:05.129
plugin which we borrowed from the[br]Ubertooth project. And yeah, that's it. We
0:12:05.129,0:12:11.100
have a LMP monitor mode. I will show that[br]in just a second. We also have an LMP
0:12:11.100,0:12:15.959
injection mode, so we can simply invoke[br]functions inside the firmware. And so we
0:12:15.959,0:12:20.410
can also invoke the function which[br]actually sends LMP packets to other
0:12:20.410,0:12:25.490
devices which are connected to our Nexus[br]5. And so, yeah, with this we have both
0:12:25.490,0:12:30.660
channels of the communication and can[br]actually send arbitrary traffic to other
0:12:30.660,0:12:38.790
devices. So, for this let's go into a[br]command line and start the framework. The
0:12:38.790,0:12:43.620
framework has a command line interface we[br]can use all of its features and interact
0:12:43.620,0:12:50.070
with the firmware and to start a monitor[br]mode, I can just type this command which
0:12:50.070,0:12:55.329
will start a Wireshark instance and also[br]install all the patches which we need into
0:12:55.329,0:13:01.079
the firmware of the phone. Now from this[br]time on, we actually have all LMP traffic
0:13:01.079,0:13:06.060
forwarded and shown in the Wireshark[br]frame, but currently we don't have a
0:13:06.060,0:13:17.379
Bluetooth connection, that's why you don't[br]see anything. Ok. Yeah, so we still need a
0:13:17.379,0:13:22.990
Bluetooth connection, right? I could just[br]pair those devices to create a connection
0:13:22.990,0:13:27.680
and then we would see LMP traffic, but I[br]want to show something else. So this will
0:13:27.680,0:13:31.089
be a combined demo actually, because[br]Bluetooth has some more interesting
0:13:31.089,0:13:36.559
features which maybe not everyone knows -[br]at least for me that was a surprise when I
0:13:36.559,0:13:42.309
first learned about this. So even if your[br]device is not being set to be discoverable
0:13:42.309,0:13:46.900
by other devices, it still accepts[br]connections from any other device, the
0:13:46.900,0:13:51.740
other device just needs to know your MAC[br]address and can simply connect to you,
0:13:51.740,0:13:56.240
without even being paired before, you[br]don't even notice this because the device
0:13:56.240,0:13:59.540
does not have to trigger the pairing[br]process, and then the user won't be
0:13:59.540,0:14:03.749
notified. And so by just finding out the[br]MAC address of any other device I can
0:14:03.749,0:14:09.160
connect to it on this LMP layer and start[br]communicating with it. And finding out the
0:14:09.160,0:14:13.240
MAC address is also not that hard. There[br]was another talk which we mention down on
0:14:13.240,0:14:17.009
the bottom of the slide, it's called[br]"Bluetooth smells like chicken" by Dominik
0:14:17.009,0:14:20.809
Spill, Michael Ossmann and Mark Steward,[br]which shows that this is actually possible
0:14:20.809,0:14:28.430
and not hard to do. So, I can actually[br]just type "connect" and give it the MAC
0:14:28.430,0:14:33.570
address of another phone.[br]J: We need again... ah great.
0:14:33.570,0:14:37.829
D: Yes. Perfect! On the right side you[br]actually see a Nexus 6P, which will be our
0:14:37.829,0:14:44.189
target. You can hopefully barely read the[br]MAC address which is shown there on the
0:14:44.189,0:14:48.430
left side as the Nexus 5 which is the[br]phone we use for for testing like the
0:14:48.430,0:14:54.920
phone which is connected to my laptop here[br]and is used for InternalBlue. And as you
0:14:54.920,0:14:58.789
also can see the Nexus 6P is currently not[br]in the Bluetooth menu, so it's not
0:14:58.789,0:15:04.920
actually discoverable by by means of[br]Bluetooth. I still can connect to it when
0:15:04.920,0:15:10.879
I actually type "connect" and the MAC[br]address this might may take a few ... no
0:15:10.879,0:15:16.110
it worked directly, perfect. So now we can[br]see that we actually have traffic on the
0:15:16.110,0:15:20.279
LMP layer. What you also might notice that[br]that on the Nexus 6P there wasn't
0:15:20.279,0:15:23.800
anything. So the user didn't notice, but I[br]have an established connection to this
0:15:23.800,0:15:28.620
other phone and you can see the LMP[br]traffic which is going on on this protocol
0:15:28.620,0:15:33.370
layer. As you can see it is quite a lot:[br]There are feature requests, version
0:15:33.370,0:15:39.519
requests, also name requests so that the[br]phones know how the name of each other is.
0:15:39.519,0:15:44.269
And yeah, from now on I can also try to[br]inject arbitrary LMP packets. For
0:15:44.269,0:15:49.379
example I can send an LMP packet with code[br]"01" which would be a name request and ask
0:15:49.379,0:15:55.259
for a name at offset 0. And you should see[br]that the name request has popped up here
0:15:55.259,0:16:01.290
and the other device even answered with[br]its name. If you scroll down here should
0:16:01.290,0:16:07.559
at some point see that we have the name[br]"Nexus 6P" because we don't renamed our
0:16:07.559,0:16:11.619
devices. But I can also send[br]arbitrary LMP packets so I'm not bound to
0:16:11.619,0:16:15.089
anything that is in the specification.[br]J: You already got the detach!
0:16:15.089,0:16:20.339
D: So the other device actually detached[br]which happens from time to time ... can
0:16:20.339,0:16:22.339
reconnect.[br]J: If we don't do anything in between we
0:16:22.339,0:16:26.990
will get a detach from the other device[br]because we didn't do a paring or something
0:16:26.990,0:16:31.879
so we re-established connection. And now[br]Dennis is going to send something that is
0:16:31.879,0:16:36.400
not specified ... just an LMP 99.[br]D: So it's even saying here this is
0:16:36.400,0:16:40.480
unknown. But as you can see the payload is[br]actually sent and the other device
0:16:40.480,0:16:45.470
correctly answers with "this is not[br]accepted and I don't want this". But you
0:16:45.470,0:16:48.670
can probably see that this is very[br]interesting for a security researcher,
0:16:48.670,0:16:52.480
because now he can see how the other[br]device happens in certain conditions, if
0:16:52.480,0:16:57.760
you send them certain packets. Yeah. Quite[br]nice to actually experiment with. OK. I
0:16:57.760,0:17:02.879
think that's it for the first demo. Let's[br]stop this and go back to this.
0:17:02.879,0:17:06.590
J: I don't need the in-screen anymore.[br]Yeah. Great. Okay.
0:17:06.590,0:17:14.760
Applause[br]D: Thank you.
0:17:14.760,0:17:17.940
J: Another thing in the Bluetooth standard[br]is that you need a possibility to pair
0:17:17.940,0:17:23.380
devices, which have no input and no output[br]capability, so they cannot show a PIN and
0:17:23.380,0:17:29.890
you cannot enter a PIN. And this is the[br]standard for any headset. But also a Man-
0:17:29.890,0:17:35.670
in-the-Middle can change the input/output[br]capabilities and then you might just get
0:17:35.670,0:17:41.480
displayed this "yes/no" pairing without a[br]PIN request. Even though your smartphone
0:17:41.480,0:17:48.580
could show more than this. And I have a[br]demo video again of the same thing. That's
0:17:48.580,0:17:53.000
this one. So on the left hand side I have[br]again a Nexus 5 on the right hand side I
0:17:53.000,0:17:59.680
have an iPhone and I am pairing them. I[br]just changed the request and the
0:17:59.680,0:18:04.030
capabilities that it's, that I'm not having[br]input output capability. So you can see on
0:18:04.030,0:18:09.180
the right hand side on the iPhone it's[br]just showing this "yes/no" question. And
0:18:09.180,0:18:12.560
on the left hand side you still have the[br]same algorithm which just does the same
0:18:12.560,0:18:21.460
thing. So pairing will succeed, there's[br]the same cryptographic routines but you
0:18:21.460,0:18:24.750
are not being warned on the iPhone and[br]that's a bit critical. So the standard is
0:18:24.750,0:18:30.150
not saying: "Please warn the user to check[br]if the other phone really has no input
0:18:30.150,0:18:34.912
output." So I just say pair and it pairs.
0:18:38.051,0:18:45.180
Yup.[br]Applause[br]
0:18:46.260,0:18:49.432
So far that's only things that are as
0:18:49.432,0:18:55.741
they are in the standard, so it's not too[br]surprising. So the question is: Can we
0:18:55.741,0:19:02.550
find more bugs? Yeah. Finding bugs in[br]Bluetooth. Actually I didn't even want to
0:19:02.550,0:19:06.170
find bugs in the beginning, I just wanted[br]to understand how everything works. So I
0:19:06.170,0:19:11.860
went through the handlers and I checked[br]the... there's these checks of the
0:19:11.860,0:19:15.810
parameters, so there is a parameter check[br]in the beginning of each handler that
0:19:15.810,0:19:21.330
shows me a bit which handler it could be[br]according to the standard. And suddenly
0:19:21.330,0:19:26.130
there is a handler which does not have any[br]check. So there's just the missing "if"
0:19:26.130,0:19:30.960
somewhere. And then I compared to firmware[br]versions that I had and found out they
0:19:30.960,0:19:39.540
silently patched that already some time[br]between June 2nd and August 19th in 2014.
0:19:39.540,0:19:44.960
But they never updated older devices, so[br]they never shipped an .hcd-patch. So I
0:19:44.960,0:19:48.860
contacted Broadcom and said: "Yeah you[br]have a problem!" and they said "No, we
0:19:48.860,0:19:53.320
don't." And I said: "You really have a[br]problem there." And so on... And then they
0:19:53.320,0:19:58.270
said: "It doesn't exist." And then I[br]showed them more and then they said "Yeah
0:19:58.270,0:20:01.900
ok, but it's not compliant to the standard[br]what you're doing!"
0:20:01.929,0:20:08.515
Laughter[br]Applause
0:20:08.515,0:20:11.650
I'm sorry, my next exploit will be[br]standard complaint.
0:20:11.650,0:20:14.780
Laughter[br]And then we discussed a bit more and then
0:20:14.780,0:20:18.000
they said: "It does not affect Wi-Fi[br]performance." Well, in my tests it did...
0:20:18.000,0:20:23.680
whatever... doesn't matter. So basically[br]you can switch off Bluetooth on another
0:20:23.680,0:20:29.590
device and then Bluetooth restarts[br]typically depending on configuration. And
0:20:29.590,0:20:34.350
as Broadcom didn't tell me much about this[br]I started testing out things on my own. So
0:20:34.350,0:20:38.130
which devices actually still have a[br]firmware that is affected in their
0:20:38.130,0:20:46.540
Broadcom chip? It's quite a lot. So it's[br]like the iPhone 6, MacBook Pro from 2016,
0:20:46.540,0:20:51.270
of course my Nexus 5, Raspberry Pi 3 and[br]so on. And this list is really not
0:20:51.270,0:20:55.640
complete this is just like, I asked my[br]students: "Can I test your smartphone?"
0:20:55.640,0:20:59.700
Some of them said: "No. Are you crazy?!"[br]Laughter
0:20:59.700,0:21:06.590
And that's the list I got just during the[br]last weeks. And this is the one I'm going
0:21:06.590,0:21:12.680
to demo. I just named it BT-B-g0ne, so you[br]can kill the Bluetooth of annoying songs
0:21:12.680,0:21:22.620
or something.[br]Applause
0:21:22.620,0:21:33.730
So I need to go into the Bluetooth here,[br]yeah, screen-in-screen... That's great. I
0:21:33.730,0:21:38.000
even had a "Bluetooth is not real" and so[br]on. That's really great. What is going on
0:21:38.000,0:21:39.430
here.[br]D: OK.
0:21:39.430,0:21:44.420
J: Yeah let's go for the demo. So first we[br]are going to patch the Nexus 5 with our
0:21:44.420,0:21:50.550
funny attack and then just press enter and[br]now it takes a while until the the iPhone
0:21:50.550,0:21:54.790
is realizing like "Oops my Bluetooth is[br]gone." So if I'm playing music you will
0:21:54.790,0:21:58.530
see it faster, the music would already[br]stop playing. Let me just enter another
0:21:58.530,0:22:01.949
time. Just... Yes, and there it's gone![br]Oops!
0:22:01.949,0:22:08.920
Applause[br]
0:22:08.924,0:22:10.974
And then it appears again and so on I can
0:22:10.974,0:22:14.940
just do it again and again and again. And[br]it's actually so fast that the other
0:22:14.940,0:22:20.070
person could not play music, because music[br]also stops playing after this disconnect.
0:22:20.070,0:22:25.440
Yeah that's the demo. Now we were[br]wondering, yeah, what is actually
0:22:25.440,0:22:31.490
happening. So actually that the crash -[br]the crash is the best case. So there is a
0:22:31.490,0:22:37.380
handler. I call it "Handler A", because[br]I'm not leaking the actual problem here.
0:22:37.380,0:22:43.180
Broadcom didn't fix it yet. So there is[br]this handler which just should take, let's
0:22:43.180,0:22:50.110
say, two arguments or something. But it[br]doesn't check the parameter range and the
0:22:50.110,0:22:55.830
compiler likes to put one handler after[br]the other. And then we just go into the
0:22:55.830,0:23:01.530
next handler, and so we have something[br]like 250 functions that we can call from
0:23:01.530,0:23:06.540
the next handler but with wrong[br]parameters. So it's a bit buggy, and
0:23:06.540,0:23:12.990
sometimes if a function expects to get[br]other parameters it just crashes. But
0:23:12.990,0:23:18.500
otherwise we can execute functions. And on[br]the Nexus 5 we looked a bit more into this
0:23:18.500,0:23:23.790
and I found out that I can enable test[br]mode. So test mode should be something
0:23:23.790,0:23:28.640
only locally to be enabled on a phone if[br]you have root access to the driver and
0:23:28.640,0:23:32.450
then you tell the driver: "I'm now going[br]to test your frequencies and so on please
0:23:32.450,0:23:35.529
go in test mode." But I can now do this[br]remotely.
0:23:37.010,0:23:42.996
Applause[br]
0:23:43.230,0:23:45.220
So I didn't bring this one as a live demo.
0:23:45.220,0:23:49.358
I mean I have a HackRF with me, we can do[br]that during Q and A, because the problem
0:23:49.358,0:23:52.910
is there is probably too much going on in[br]the spectrum here and you wouldn't see the
0:23:52.910,0:24:01.150
test mode starting anyway. So I'm just[br]doing the attack and then on the left hand
0:24:01.150,0:24:04.330
side, I just took a quick pause, you can[br]see the test mode, so that's just the
0:24:04.330,0:24:09.690
default test mode hopping around in all[br]channels. The packets now appear a bit out
0:24:09.690,0:24:15.170
of order because I just put them into a[br]queue, send them. This "???" payload is
0:24:15.170,0:24:19.910
the malicious payload. I just send[br]"test_control" and "test_activate". And
0:24:19.910,0:24:28.120
first they get this not_accepted. And then[br]after this "???" payload you can see that
0:24:28.120,0:24:32.510
it's accepted. And on the left hand side[br]you can still see that there is the test
0:24:32.510,0:24:39.977
mode going on, so really block things for[br]longer time. And then it's accepted, magic!
0:24:42.448,0:24:48.648
Applause
0:24:48.860,0:24:52.330
If you combine this with disabling[br]adaptive frequency hopping you can even
0:24:52.330,0:24:58.080
force the other device, which is also then[br]in test mode, to stop hopping for a while
0:24:58.080,0:25:02.880
and then just jam a selected frequency, so[br]you could also jam a selected Wi-Fi
0:25:02.880,0:25:07.750
frequency that this device is currently[br]using. And it's a combo chip, so you would
0:25:07.750,0:25:13.360
really be on the same antenna. We can[br]confirm this works on Nexus 5 and Xperia
0:25:13.360,0:25:18.950
Z3, because they both have to be same[br]BCM4339 chip. It might also work on other
0:25:18.950,0:25:24.630
devices with that chip. It's a bit random[br]to find out what is in there. You need to
0:25:24.630,0:25:31.740
find teardowns and on. So when finding[br]this bug we started developing a
0:25:31.740,0:25:37.720
toolchain. So Dennis added a feature for[br]tracepoints. You can add now a tracepoint
0:25:37.720,0:25:41.410
to a function which is then called once[br]and dumps all the registers and the stack
0:25:41.410,0:25:47.650
and heap. I then fed this into an[br]emulation framework, which is currently
0:25:47.650,0:25:52.510
quite slow with unicorn and radare2,[br]but I get a full call trace, which is very
0:25:52.510,0:25:56.960
nice to look at. So I have an idea what is[br]going on, what is changed in the memory.
0:25:56.960,0:26:01.171
And I currently have a student working on[br]a qemu/gdb set up, which is faster but
0:26:01.171,0:26:06.870
producing less output, just to fuzz more[br]efficiently. However, you get really a lot
0:26:06.870,0:26:11.060
of output that we weren't able to[br]completely analyze yet, so there's
0:26:11.060,0:26:19.580
probably more. Maybe tell you somewhen[br]later. Now you need to somehow fix that
0:26:19.580,0:26:23.050
bug. And that's that's really a problem,[br]and that's also why I didn't tell you the
0:26:23.050,0:26:29.200
exact payload that is causing these[br]issues. Because, well, the fix would be in
0:26:29.200,0:26:33.880
one of those .hcd-files. It would be[br]plaintext. It would not be signed and it
0:26:33.880,0:26:38.750
would just tell you directly "This handler[br]is vulnerable in exactly this position!"
0:26:38.750,0:26:44.080
and so on. The patch is just 14 bytes, but[br]you need to install it and then it's easy
0:26:44.080,0:26:48.720
to understand what it does, right? So I[br]had an idea: Let's do some more generic
0:26:48.720,0:26:54.390
fix. So what I planned to do was having a[br]generic filter, filtering some packets
0:26:54.390,0:26:58.270
like that you won't reply to, pings[br]connection establishments and so on, to
0:26:58.270,0:27:04.800
untrusted devices. And then just over[br]Christmas I started testing that one with
0:27:04.800,0:27:10.650
bigger setups, with more phones and so on.[br]And then I realized: OK if I throw away
0:27:10.650,0:27:16.210
some packets and the other device does not[br]expect me to throw away packets, then the
0:27:16.210,0:27:23.130
Bluetooth stack of a device which now[br]tries to connect to me is going to crash.
0:27:23.130,0:27:26.730
So I had the next bug! So I tried to fix[br]one bug. I get the next bug, you know
0:27:26.730,0:27:34.650
this. So I actually cannot release any[br]fix, because ... uh. Yeah. Because all of
0:27:34.650,0:27:43.710
them still cause the next bug and so on.[br]So how long will this bug be around?
0:27:43.710,0:27:47.900
Pretty long probably because there is some[br]devices which are no longer getting vendor
0:27:47.900,0:27:53.000
updates. It needs to be in the vendor[br]update, it needs to be this special .hcd-
0:27:53.000,0:27:59.960
file. And so on. I mean we can also[br]publish .hcd-files if needed. That's
0:27:59.960,0:28:04.100
possible with our framework. That's the good[br]news, but it will probably never be an
0:28:04.100,0:28:09.070
official update. And the vendor updates[br]will obviously leak the vulnerability. So
0:28:09.070,0:28:15.790
it's chicken-egg. As we found this bug[br]still to be present in devices that were
0:28:15.790,0:28:21.610
produced in 2016, we recommend you to turn[br]off Bluetooth - especially if you have a
0:28:21.610,0:28:29.430
Broadcom chipset produced before 2017.[br]But in general just turn it off. That's
0:28:29.430,0:28:34.720
probably the safest option. And we found[br]out that very old devices having something
0:28:34.720,0:28:40.420
like Bluetooth 3.0 are not vulnerable,[br]because that feature that we used didn't
0:28:40.420,0:28:46.744
exist back then. But still it's a large[br]number of devices having this issue.
0:28:48.796,0:28:50.680
So, thanks for listening.[br]
0:28:50.682,0:29:02.660
Long Applause
0:29:03.140,0:29:09.270
Herald: And again if you have questions we[br]have 8 microphones in the hall. Please
0:29:09.270,0:29:12.767
line up at the microphones and you can ask[br]your questions.
0:29:15.539,0:29:18.608
The Signal Angel has the first[br]question from the Internet.
0:29:18.637,0:29:22.973
Signal Angel: Yes some of the Internet[br]asked if you can guess the Bluetooth MAC
0:29:22.990,0:29:30.500
address from the wifi MAC address of a device.[br]Jiska: Yes. So if I go into... Can we
0:29:30.500,0:29:38.800
switch the camera on again? On my magic[br]box here. Is that possible? Yes. So
0:29:38.800,0:29:49.840
actually, if you go to the "Settings",[br]"About", and then you will see that the
0:29:49.840,0:29:53.130
WiFi and Bluetooth MAC address, they are[br]just off by one.
0:29:53.130,0:30:02.260
Laughter and applause[br]Dennis: So yeah. You have to note however
0:30:02.260,0:30:06.640
that this is not the case with every[br]phone. So usually I think new phones
0:30:06.640,0:30:13.090
actually try to randomize their Wi-Fi MAC[br]address to be not traceable anymore. Not
0:30:13.090,0:30:18.670
sure which devices do that. I think the[br]Nexus 6P does that so the first part will
0:30:18.670,0:30:24.040
be the same, because it specifies which[br]vendor this chip was made from. But then,
0:30:24.040,0:30:28.590
the lower and least significant bits will[br]change. So it's sometimes possible,
0:30:28.590,0:30:32.890
sometimes not. Yeah. I think that's the[br]answer to this question.
0:30:32.890,0:30:38.300
Herald: OK. The next question was from the[br]microphone 8 at the very end of the hall.
0:30:38.726,0:30:41.929
Eight: Hello. Thanks for your talk. I was
0:30:41.929,0:30:47.160
wondering in your second demo, you showed[br]us how you connect to a device, just using
0:30:47.160,0:30:53.320
the MAC address and this device was not[br]advertising his name. How do you find a
0:30:53.320,0:30:58.640
MAC address, if it's not advertising?[br]Dennis: Yeah. So there are ways to find
0:30:58.640,0:31:04.750
out the MAC address of devices which are[br]nearby you. So for example if your device
0:31:04.750,0:31:07.880
has Bluetooth turned on but it's not[br]discoverable at the moment, but you're
0:31:07.880,0:31:12.060
listening to music on your headphones or[br]if you have a smartwatch connected or
0:31:12.060,0:31:16.290
any other Bluetooth device connected, then[br]you will certainly send Bluetooth traffic
0:31:16.290,0:31:19.940
and you can sniff that from the air. For[br]example with a software-defined radio or
0:31:19.940,0:31:26.310
an Ubertooth. And so in the talk we[br]mentioned and we also have a link to this
0:31:26.310,0:31:30.420
in the slide, I guess it was here,[br]"Bluetooth smells like chicken". Michael
0:31:30.420,0:31:35.460
Ossman and Dominic Spill, they actually[br]explained very detailed how you can then
0:31:35.460,0:31:40.290
infer the MAC address from those packets[br]you sniffed. And, yeah, it's doable. It's
0:31:40.290,0:31:42.940
not as easy as with Wi-Fi but it's[br]certainly possible.
0:31:42.940,0:31:45.900
Eight: Thank you.[br]Herald: Okay. The next question was at
0:31:45.900,0:31:50.360
Microphone number one.[br]One: Thanks for your talk and demos. The
0:31:50.360,0:31:59.580
question is, does this firmware have any[br]mitigations against exploitation? And if
0:31:59.580,0:32:03.000
we imagine that it has, would it help[br]against such bugs?
0:32:03.000,0:32:10.630
Dennis: So. There's no, like real address[br]randomization, kind of the obvious way,
0:32:10.630,0:32:14.930
because there's... Most of the things are[br]actually global offsets inside the
0:32:14.930,0:32:18.130
firmware. So everything is at fixed[br]addresses, like you would use global
0:32:18.130,0:32:25.180
variables all over. There's also the RAM,[br]it's actually executable, so you can
0:32:25.180,0:32:29.120
execute on the stack, you can execute on[br]the heap, everywhere. So there's no real
0:32:29.120,0:32:34.550
mitigations for such a exploitation. It's[br]like, I don't think even the newer ones
0:32:34.550,0:32:36.840
have that sort of, and the Nexus 5[br]obviously.
0:32:36.840,0:32:41.800
Jiska: And another thing that really helps[br]us. So LMP has a version_request,
0:32:41.800,0:32:46.580
version_response, which is always sent. So[br]I can ask a device actually: Do you have a
0:32:46.580,0:32:51.560
vulnerable firmware and which version? And[br]then I can run exactly the exploit. And
0:32:51.560,0:32:55.550
the firmware, I mean, the firmware is[br]standard and I can just run the addresses
0:32:55.550,0:33:01.470
that I know for a certain firmware.[br]Herald: Okay. The next question was at
0:33:01.470,0:33:05.630
microphone number two. Then again number[br]one, three and five.
0:33:05.630,0:33:10.680
Two: Hi. Thanks for the work especially[br]for BT-B-g0ne since like it's the TV-B-
0:33:10.680,0:33:17.270
Gone. And I'm not sure of which kind of[br]iPhone that works, because you had a slide
0:33:17.270,0:33:22.230
about iPhone up until 6, and then you had[br]a slide that saying if the chip is older
0:33:22.230,0:33:26.480
than 2017. So does that work with the last[br]phones as well?
0:33:26.480,0:33:30.160
Jiska: Only up to iPhone 6 that was used[br]was the latest I could get. So if you have
0:33:30.160,0:33:34.180
an iPhone 8 or something, our attack does[br]not work.
0:33:34.180,0:33:38.580
Two: So you're going to work on it?[br]Because a lot of people are playing very
0:33:38.580,0:33:42.460
bad music and have new phones.[br]Laughter
0:33:42.460,0:33:48.070
Jiska: You mean the attack. The attack is[br]not working on iPhone 6, but the general
0:33:48.070,0:33:53.340
framework like patching .hcd-files or[br]changing the firmware will obviously work
0:33:53.340,0:33:55.910
on any Broadcom chip.[br]Two: Okay, thanks.
0:33:55.910,0:33:58.980
Dennis: Broadcom actually uses this[br]mechanism for all their chips, all their
0:33:58.980,0:34:03.861
Bluetooth chips, so you can use this[br]framework for every Broadcom chip, every
0:34:03.861,0:34:07.650
device that has a Broadcom chip. You only[br]need to do the reverse engineering, as to
0:34:07.650,0:34:12.168
get like the real addresses and offsets[br]inside the firmware to do meaningful
0:34:12.168,0:34:14.489
patches.[br]Jiska: But for this you always need to be,
0:34:14.489,0:34:18.659
to have a rooted device. You need root[br]access on the device to run our patching
0:34:18.659,0:34:20.819
framework.[br]Two: Okay. Thanks.
0:34:20.819,0:34:23.659
Herald: Okay. Now the question at[br]microphone number one.
0:34:23.659,0:34:28.418
One: Do you have a list of vulnerable[br]chipsets? So I can check if my phone is
0:34:28.418,0:34:31.819
vulnerable if it's not like in those[br]slides.
0:34:31.819,0:34:36.619
Jiska: Yeah, but it's very incomplete. So[br]I also have that, the version numbers and
0:34:36.619,0:34:42.309
subversion numbers of those phones. But[br]just consider the time range. So if your
0:34:42.309,0:34:47.739
smartphone does Bluetooth 4.0 to 4.2 and[br]it has a Broadcom chip then it's very
0:34:47.739,0:34:52.789
likely to be vulnerable.[br]Herald: Okay, now the question from
0:34:52.789,0:34:58.750
microphone number three.[br]Three: Thank you for the codes and the
0:34:58.750,0:35:06.220
talk. Quick question, so have you looked[br]at a car Bluetooth? And if not, are you
0:35:06.220,0:35:12.639
thinking about it?[br]Dennis: So I actually used this tool. As I
0:35:12.639,0:35:17.520
mentioned previously, we are also able to[br]test other vulnerabilities, for example
0:35:17.520,0:35:23.349
this fixed coordinate invalid curve[br]attack. And so I used my tool to actually
0:35:23.349,0:35:27.359
check if a car radio was vulnerable to[br]this fixed coordinate invalid curve attack
0:35:27.359,0:35:31.440
that was released this summer. So it's[br]basically patched since half a year but
0:35:31.440,0:35:37.030
the car was still vulnerable to this. So[br]the framework is basically usable to test
0:35:37.030,0:35:41.440
car radios as well, but I haven't like[br]specifically looked into a car radio.
0:35:41.440,0:35:45.130
Three: Thank you.[br]Herald: Okay. Now a question from
0:35:45.130,0:35:49.230
Microphone number five. Then we take a[br]question from the Internet and microphone
0:35:49.230,0:35:55.990
number six.[br]Five: What is the attack surface exposed
0:35:55.990,0:36:02.779
by your exploits? What's the worst case?[br]Could you manipulate memory or something?
0:36:02.779,0:36:07.270
Jiska: Worst case it's hard to estimate. I[br]mean we can change some memory addresses
0:36:07.270,0:36:12.190
at least in the Nexus 5. And for each[br]smartphone there are other functions by
0:36:12.190,0:36:16.770
the compiler put there. So to really know[br]what is happening, we would now need to
0:36:16.770,0:36:22.890
analyze like really tons of firmwares and[br]check what is in there and do some
0:36:22.890,0:36:28.749
fuzzing. We already found out that some[br]things only happen if you combine multiple
0:36:28.749,0:36:32.320
packets and so on. So it's really hard to[br]estimate what is the worst case. So the
0:36:32.320,0:36:36.920
very worst case would be, so to say, that[br]you can run arbitrary code in the
0:36:36.920,0:36:43.430
Bluetooth, in the Bluetooth firmware[br]itself, and then the next worst case would
0:36:43.430,0:36:47.660
be if there would be another vulnerability[br]in the driver, that you could escape
0:36:47.660,0:36:52.660
the firmware. So that would be the next[br]step. But that really requires an exploit
0:36:52.660,0:36:58.369
chain. So the very worst case would be[br]something similar. So there has been
0:36:58.369,0:37:03.970
vulnerabilities in the Wi-Fi part of[br]Broadcom chips where you had the
0:37:03.970,0:37:11.540
possibility to really run an exploit chain[br]which then rooted a device in the end. But
0:37:11.540,0:37:14.880
it's hard to estimate if you can do it[br]with this or not.
0:37:14.880,0:37:18.280
Herald: OK. Now the question from the[br]Internet please.
0:37:18.280,0:37:22.940
Internet: Do you know if any older but[br]still supported devices like old MacBooks
0:37:22.940,0:37:28.759
are patched and can you actually detect[br]this in any way other than a chip crash?
0:37:28.759,0:37:38.100
Jiska: Not really, so we can try to not[br]crash the chip by first checking if it is
0:37:38.100,0:37:42.810
sending appropriate answers, but typically[br]the really only thing to be sure is that
0:37:42.810,0:37:48.260
it crashes. So that so far is the only[br]way, because I mean obviously, if Broadcom
0:37:48.260,0:37:52.020
would tell "the following chips are[br]vulnerable", which they didn't so far,
0:37:52.020,0:37:57.430
because that's also to protect themselves[br]probably, then you could be sure. But yeah
0:37:57.430,0:38:01.979
as of now that's the only way to check it.[br]Herald: Thank you. Now the question from
0:38:01.979,0:38:06.200
microphone number six please.[br]Six: Yeah. Would it be possible to
0:38:06.200,0:38:13.120
increase the Bluetooth radio transmission[br]power by patching the firmware? So that
0:38:13.120,0:38:18.209
Bluetooth works across entire[br]buildings and not only in a single room?
0:38:18.209,0:38:23.030
Dennis: Yeah. So the thing is, we are[br]actually now patching the firmware of the
0:38:23.030,0:38:27.069
chip, and the firmware does like all the[br]the link layer stuff of Bluetooth. The
0:38:27.069,0:38:31.480
real physical part is probably done in[br]another component inside the chip which
0:38:31.480,0:38:36.210
may be running another kind of small real-[br]time firmware and we haven't found that
0:38:36.210,0:38:40.079
yet. We are still looking for it because[br]that must be in there somewhere, like that
0:38:40.079,0:38:44.529
Bluetooth modem and maybe we can actually[br]change the settings for this modem. I
0:38:44.529,0:38:48.760
don't think it will be too drastical. But[br]maybe if you're in different areas of the
0:38:48.760,0:38:52.049
world and like your Bluetooth has[br]different strengths in different areas of
0:38:52.049,0:38:56.010
the world, you can maybe manipulate that.[br]But we haven't found it yet.
0:38:56.010,0:38:59.090
Six: OK. Thank you.[br]Herald: Okay. Next question is coming from
0:38:59.090,0:39:03.730
microphone number four.[br]Four: Does the Bluetooth chipset have
0:39:03.730,0:39:08.599
access to system RAM?[br]Dennis: Sorry I didn't get the last word.
0:39:08.599,0:39:09.923
Jiska: The system rights or what do you[br]mean?
0:39:09.923,0:39:13.770
Four: The system RAM, memory.[br]Dennis: You mean the memory of the main
0:39:13.770,0:39:16.499
processor like where Android or iOS is[br]running on?
0:39:16.499,0:39:19.589
Four: Yes.[br]Dennis: No it's not like as with Wi-Fi
0:39:19.589,0:39:23.940
where you have direct memory access. But[br]Bluetooth, the HCI interface is the only
0:39:23.940,0:39:29.569
interface between those two processors.[br]And this is usually done over either USB
0:39:29.569,0:39:36.329
or in the Nexus 5 is actually UART.[br]Herald: Next question is coming from
0:39:36.329,0:39:39.930
microphone number three.[br]Three: Many thanks for the enlightening
0:39:39.930,0:39:43.750
and scary talk. I missed a little bit of[br]the beginning maybe that question was
0:39:43.750,0:39:50.970
inside there. Did you or do you considered[br]to disclose this vulnerability for example
0:39:50.970,0:39:56.369
to BSI (Bundesamt für Sicherheit in der[br]Informationstechnik)? As I would consider
0:39:56.369,0:40:01.930
their obligation to inform general public[br]like put a note on their website saying:
0:40:01.930,0:40:06.900
"Look, if you're running a certain[br]smartphone you're vulnerable to a certain
0:40:06.900,0:40:11.810
attack!" And that would put much more[br]stress on the vendors to really look into
0:40:11.810,0:40:14.124
this.[br]Jiska: Yeah that sounds like a good
0:40:14.124,0:40:22.480
option. So far we're, so we asked Broadcom[br]when we can publish things and at least
0:40:22.480,0:40:26.690
they agreed that it's no problem to[br]publish it in summer, then it would be
0:40:26.690,0:40:31.029
public for everyone. But yeah, BSI would[br]also be a nice option.
0:40:31.939,0:40:33.589
Three: Thank you.[br]
0:40:33.589,0:40:36.440
Herald: OK. Is there another question[br]from the Internet?
0:40:37.024,0:40:38.624
…
0:40:40.409,0:40:45.699
Please switch on the[br]microphone for the Internet.
0:40:45.699,0:40:50.829
Internet: Hello? Hi. So do you know if any[br]devices have been patched yet, which have
0:40:50.829,0:40:55.229
not been released after 2017, or are there[br]no rolled out patches?
0:40:55.229,0:41:01.430
Jiska: I don't think so. So, it took[br]Broadcom two months to actually confirm
0:41:01.430,0:41:05.700
that there is this vulnerability. So on[br]December 3rd they said, ooops it really
0:41:05.700,0:41:12.279
exists. And then on December 9th, they[br]were like: "Ooh, do you really plan to do
0:41:12.279,0:41:15.430
that talk here?!"[br]Laughter
0:41:15.430,0:41:22.430
And I did the most recent iOS update on[br]the iPhone 6 that I just showed you. And
0:41:22.430,0:41:26.490
this one is still valuable. I think it[br]takes some time for testing. So I would
0:41:26.490,0:41:32.309
say the first patches will come out maybe[br]in 1, 2 months, but we don't know.
0:41:32.309,0:41:35.670
Herald: Okay. One last quick question from[br]microphone number one.
0:41:35.670,0:41:40.180
One: So is it … do you think it is[br]possible to trace back when was this
0:41:40.180,0:41:44.900
vulnerability introduced, so we can go[br]back and try to hack old devices that
0:41:44.900,0:41:49.670
probably have the same firmware or[br]firmware vulnerability? Because they
0:41:49.670,0:41:55.539
should be backward compatible, right? So[br]if the same handler is implemented I
0:41:55.539,0:42:00.130
know in 2012 first and for the first time[br]then uh...
0:42:00.130,0:42:02.510
Jiska: Yeah.[br]One: Probably the devices can be narrowed
0:42:02.520,0:42:04.829
down, right?[br]Jiska: So at least.. so the Nexus 5 has a
0:42:04.829,0:42:14.990
firmware from 2012 actually. So somewhere,[br]so the June 2nd is when it still existed
0:42:14.990,0:42:21.220
in 2014. I don't know. So in each firmware[br]there is a build date and I would then
0:42:21.220,0:42:25.559
need to extract the firmware of vulnerable[br]devices and so on, so it's a long process,
0:42:25.559,0:42:28.690
but at least the vulnerability was there[br]for multiple years.
0:42:30.070,0:42:34.530
Herald: Okay now give please a huge round[br]of applause for Jiska Classen
0:42:34.530,0:42:36.540
and Dennis Mantz for their talk.[br]
0:42:36.540,0:42:37.310
Applause
0:42:37.310,0:42:39.291
Dennis: Thank you![br]Applause
0:42:39.291,0:42:45.166
35C3 outro music
0:42:45.166,0:43:03.000
subtitles created by c3subtitles.de[br]in the year 2019. Join, and help us!