-
35c3 preroll music
-
Herald: So, Dennis, the left speaker,
finished his M.Sc. in IT security this
-
year. The next talk is based on his master
thesis, InternalBlue, which is a Bluetooth
-
experimentation framework for which he
even received a prize. Jiska, the right
-
speaker, or for you left speaker, has been
his supervisor during the thesis and she
-
loves breaking things. After several talks
about wireless security, software-defined
-
radio and Fitbits, she is now talking
about Bluetooth. Please welcome on stage
-
Dennis Mantz and Jiska Classen to their
talk "Dissecting Broadcom Bluetooth".
-
Applause
Dennis: Yeah. Thank you for the
-
introduction and welcome you all to our
talk. I'm Dennis and as said I choose
-
Bluetooth as the topic for my master's
thesis and the outcome basically was I
-
reverse engineered the firmware of a
Bluetooth controller which was
-
manufactured by Broadcom, and I built a
little experimentation framework around
-
it. And today we are not only going to
present the framework, but also various
-
kinds of use cases around it, and we also
brought along some demos. Now, if you
-
start such a big reversing project you
certainly know that this will not be an
-
easy task and also quite time consuming.
So you might want to ask: why did we do
-
that in the first place? So there are
several good reasons. For one, dissecting
-
the firmware and exploring it for
reverse engineering is really helpful if
-
you want to get insights from a security
perspective. And this is what I had in
-
mind when I first started my thesis. But
then secondly and even better, once you're
-
able to modify the firmware you can
actually leverage this fully featured and
-
working Bluetooth implementation to be
your very own experimentation platform, where
-
you can add new features or can also alter
existing behavior, and it almost feels
-
like you can add a kind of open source
touch to a closed source and proprietary
-
platform which I really like about this
project. Certainly this requires a certain
-
background in many different departments
like security, code analysis, wireless
-
signals, embedded programming, and also
not every researcher has resources and
-
time to do such a reverse engineering
project, but we think that the outcomes of
-
this project are really helpful and
beneficial for the security community. So,
-
and last but not least we actually really
like reverse engineering. So we already
-
had great experiences with similar
projects in the past. For example, some of
-
you might know the NexMon project, where
we reverse engineered and also modified
-
the firmware of a Wi-Fi controller. Okay,
before we show our work, we first have to
-
introduce a few Bluetooth protocols which
we will be mentioning quite a lot
-
throughout this talk. So the first one
would be the host controller interface.
-
Some of you might know that, it's the HCI,
and it's a protocol layer between the
-
Bluetooth controller and the host system,
where the health system would be for
-
example an Android phone, or iOS, or
Linux, or any other operating system which
-
implements those upper layers of the
Bluetooth protocol stack, and all the
-
lower layers are actually implemented
inside the Bluetooth controller. And one
-
of them would be for example the Link
Manager Protocol, the LMP. And this one is
-
also really interesting. It actually
manages connections to other remote
-
Bluetooth devices. For example, pairing is
also done on this protocol layer. And
-
what's an interesting difference is that
the Link Manager Protocol is actually
-
transmitted over the air to communicate
with other devices, whereas the HCI
-
protocol is only used locally to
communicate between the operating system
-
and the Bluetooth controller. And another
interesting fact to know is that the HCI
-
is actually able to be observable from the
host site. So if you maybe tried to capture
-
on a Bluetooth interface in Linux before,
or if you turned on the BT snoop log
-
feature under the development settings in
Android, you probably have seen HCI packets
-
in Wireshark before, because this is an
easy task to do. However you probably did
-
not see LMP packets in Wireshark before,
because this protocol layer is actually
-
implemented inside the controller and it's
not observable from the host side. You
-
won't see those packets if you just
capture on a Bluetooth interface because
-
you can only see what's above the HCI
layer. And so the other thing is that you
-
cannot also simply sniff this from the air
because Bluetooth has frequency hopping
-
and encryption. So it's a lot harder to
sniff those packets from the air just as
-
with Wi-Fi for example. But today we try
to change that. Now I will introduce the
-
framework I developed and show its
features, and later we go into more
-
details and also present some demos. As
already mentioned, we named the framework
-
InternalBlue. It's open source and you can
find it on GitHub and currently it's only
-
compatible with the Nexus 5 if you want to
use all of its features, but we are also
-
working to port it to other Bluetooth
chips in other smartphones, and also other
-
platforms like the Raspberry Pi, and yeah,
soon you will have more devices which are
-
supported by this framework. We also
already gave a talk where we introduced
-
the framework and give some details about
the internals and how it works. So if
-
you're interested and want to learn more
then you should check out our previous
-
talk which was also recorded and you can
find a link down at the bottom of the
-
slide as well. Basically in a nutshell we
use vendor specific HCI commands which are
-
implemented by Broadcom and allow us to
read out and modify the firmware while the
-
chip is actually running. And on top of
this, we basically implemented a Python
-
API to interact with the firmware, and we
use this API to then implement all kinds
-
of features which we find interesting. For
example one of the first things we did was
-
implementing such a LMP monitoring mode so
that we can finally see LMP traffic on our
-
laptop in Wireshark. And what comes along
with this is that we are also able to
-
inject arbitrary LMP packets inside
existing Bluetooth connections. And this
-
turned out to be also very interesting
because then we can test how other devices
-
react to maybe packets they don't accept
or yeah, at least it's very good for
-
experimentation and for example we use
this to write a little proof of concept
-
script for the fixed coordinate invalid
curve attack that was released this
-
summer, not by us but by other
researchers, and we were able to actually
-
prove that other devices are vulnerable to
this attack. So this is a really helpful
-
and practical tool. Also, at some point we
found a crash our own. So we found back in
-
some older Broadcom firmwares which allows
us to remotely crash the firmware in some
-
of the Broadcom chips, and in some cases
we are even able to execute a limited set
-
of functions, so this might be even more
interesting than just a crash - but more
-
on that later. Now if you first start with
the main thing about this is, how do we
-
actually modify the firmware, How is
patching being done? And I already said
-
that Broadcom uses those vendor-specific
HCI commands. To read them out, they are:
-
READ_RAM, WRITE_RAM and LAUNCH_RAM, and
they do exactly what you think they would
-
do. So basically we are able to read and
write in the address space of the
-
firmware, and also to execute arbitrary
code snippets in the context of the
-
firmware. And this is pretty powerful.
Broadcom actually uses this to do their
-
firmware updates, so they ship so-
called HCD files, which are files that
-
contain firmware updates. If you have a
Broadcom chip inside your laptop or inside
-
your phone, you should find such a file
with the extension ".hcd" on your
-
filesystem, and those files actually
contain just a sequence of those commands
-
to upload all the changes and patches, and
they're even able to do temporary patches
-
to the ROM of the firmware by another
mechanism that they call "Patchram." We also
-
had to reverse engineer this and now we
are finally able to do all those patching
-
ourselves. Now, what is also interesting
is that those files, the .hcd files, are
-
neither encrypted nor signed. So it's
quite easy to actually modify them once
-
you understand how they work. And also the
firmware itself on the controller is not
-
obfuscated. So there are basically no
major attempts done by Broadcom to prevent
-
anyone to reverse engineer and modify
this firmware. Currently, we write our
-
code and assembler, so we write assembler
patches, but we're working on including
-
this in our NexMon project to finally be
able to write patches in C code, which
-
will be more comfortable and portable.
First of course we have to do the
-
reversing.
Jiska: Yeah. So as Dennis told you the
-
code is not obfuscated but there is no
strings and no function names. So you end
-
up with thousands of functions that just
have no name, it's just sub 1, sub 2, sub
-
some-thousand something. And then there is
a tool that I used which is called CodeCut
-
to try to separate those functions into
modules. But also the modules don't really
-
tell you that much because the problem is:
then you have hundreds of modules and then
-
you know which modules are central and you
might to start reversing but it's not
-
really fun. You have 2800 pages of
Bluetooth standards, you might have some
-
parameter checks in there, so you have
bounds which the parameters should be in,
-
and then you search for those numbers
again in assembly code and you might find
-
some matches and then you have concrete
functions. So that's what we both did for
-
months. staring at standards, staring at
the code. Then people asked me: "Yes,
-
that's not nice, but does it work on on
recent devices?" And now the problem is
-
even the Nexus 6P has a firmware from end
of 2014. So I just decided to buy a
-
development board, which has also a
slightly outdated firmware, I mean just
-
one year old. Meanwhile, this part of
Broadcom was acquired by Cypress so it's
-
called Cypress. But it doesn't matter,
it's still the same mechanisms in there.
-
And I was able to use the same HCI
commands, so I can still modify the
-
firmware on this, I can extract the
firmware, and actually I just got that on
-
December 6, and 3 days later I had all
function names because somewhere someone
-
forgot a patch.elf with all function names
in the development kit. So that's 11 000
-
function names, 3000 object names. Nice.
Yeah.
-
Applause
J: So, buy development kits earlier.
-
Laughter
D: OK. Let's get closer to the first demo.
-
So as mentioned we have this Link Manager
Protocol which does interesting things
-
like pairing and all kinds of stuff. And
it's implemented in the firmware so we
-
cannot really see it from outside, we
cannot capture it in Wireshark. And we
-
wanted to change that. So we wrote a patch
that will actually hook some of the
-
functions inside the firmware, those that
are handling LMP, to actually forward all
-
the traffic over the HCI interface back to
our Android phone. And then on the Android
-
phone we use a Android Bluetooth stack
which has debugging features compiled into
-
it so that we can also forward all the HCI
traffic via TCP to our host computer. And
-
from there we can then show it in
Wireshark. We use a custom LMP dissector
-
plugin which we borrowed from the
Ubertooth project. And yeah, that's it. We
-
have a LMP monitor mode. I will show that
in just a second. We also have an LMP
-
injection mode, so we can simply invoke
functions inside the firmware. And so we
-
can also invoke the function which
actually sends LMP packets to other
-
devices which are connected to our Nexus
5. And so, yeah, with this we have both
-
channels of the communication and can
actually send arbitrary traffic to other
-
devices. So, for this let's go into a
command line and start the framework. The
-
framework has a command line interface we
can use all of its features and interact
-
with the firmware and to start a monitor
mode, I can just type this command which
-
will start a Wireshark instance and also
install all the patches which we need into
-
the firmware of the phone. Now from this
time on, we actually have all LMP traffic
-
forwarded and shown in the Wireshark
frame, but currently we don't have a
-
Bluetooth connection, that's why you don't
see anything. Ok. Yeah, so we still need a
-
Bluetooth connection, right? I could just
pair those devices to create a connection
-
and then we would see LMP traffic, but I
want to show something else. So this will
-
be a combined demo actually, because
Bluetooth has some more interesting
-
features which maybe not everyone knows -
at least for me that was a surprise when I
-
first learned about this. So even if your
device is not being set to be discoverable
-
by other devices, it still accepts
connections from any other device, the
-
other device just needs to know your MAC
address and can simply connect to you,
-
without even being paired before, you
don't even notice this because the device
-
does not have to trigger the pairing
process, and then the user won't be
-
notified. And so by just finding out the
MAC address of any other device I can
-
connect to it on this LMP layer and start
communicating with it. And finding out the
-
MAC address is also not that hard. There
was another talk which we mention down on
-
the bottom of the slide, it's called
"Bluetooth smells like chicken" by Dominik
-
Spill, Michael Ossmann and Mark Steward,
which shows that this is actually possible
-
and not hard to do. So, I can actually
just type "connect" and give it the MAC
-
address of another phone.
J: We need again... ah great.
-
D: Yes. Perfect! On the right side you
actually see a Nexus 6P, which will be our
-
target. You can hopefully barely read the
MAC address which is shown there on the
-
left side as the Nexus 5 which is the
phone we use for for testing like the
-
phone which is connected to my laptop here
and is used for InternalBlue. And as you
-
also can see the Nexus 6P is currently not
in the Bluetooth menu, so it's not
-
actually discoverable by by means of
Bluetooth. I still can connect to it when
-
I actually type "connect" and the MAC
address this might may take a few ... no
-
it worked directly, perfect. So now we can
see that we actually have traffic on the
-
LMP layer. What you also might notice that
that on the Nexus 6P there wasn't
-
anything. So the user didn't notice, but I
have an established connection to this
-
other phone and you can see the LMP
traffic which is going on on this protocol
-
layer. As you can see it is quite a lot:
There are feature requests, version
-
requests, also name requests so that the
phones know how the name of each other is.
-
And yeah, from now on I can also try to
inject arbitrary LMP packets. For
-
example I can send an LMP packet with code
"01" which would be a name request and ask
-
for a name at offset 0. And you should see
that the name request has popped up here
-
and the other device even answered with
its name. If you scroll down here should
-
at some point see that we have the name
"Nexus 6P" because we don't renamed our
-
devices. But I can also send
arbitrary LMP packets so I'm not bound to
-
anything that is in the specification.
J: You already got the detach!
-
D: So the other device actually detached
which happens from time to time ... can
-
reconnect.
J: If we don't do anything in between we
-
will get a detach from the other device
because we didn't do a paring or something
-
so we re-established connection. And now
Dennis is going to send something that is
-
not specified ... just an LMP 99.
D: So it's even saying here this is
-
unknown. But as you can see the payload is
actually sent and the other device
-
correctly answers with "this is not
accepted and I don't want this". But you
-
can probably see that this is very
interesting for a security researcher,
-
because now he can see how the other
device happens in certain conditions, if
-
you send them certain packets. Yeah. Quite
nice to actually experiment with. OK. I
-
think that's it for the first demo. Let's
stop this and go back to this.
-
J: I don't need the in-screen anymore.
Yeah. Great. Okay.
-
Applause
D: Thank you.
-
J: Another thing in the Bluetooth standard
is that you need a possibility to pair
-
devices, which have no input and no output
capability, so they cannot show a PIN and
-
you cannot enter a PIN. And this is the
standard for any headset. But also a Man-
-
in-the-Middle can change the input/output
capabilities and then you might just get
-
displayed this "yes/no" pairing without a
PIN request. Even though your smartphone
-
could show more than this. And I have a
demo video again of the same thing. That's
-
this one. So on the left hand side I have
again a Nexus 5 on the right hand side I
-
have an iPhone and I am pairing them. I
just changed the request and the
-
capabilities that it's, that I'm not having
input output capability. So you can see on
-
the right hand side on the iPhone it's
just showing this "yes/no" question. And
-
on the left hand side you still have the
same algorithm which just does the same
-
thing. So pairing will succeed, there's
the same cryptographic routines but you
-
are not being warned on the iPhone and
that's a bit critical. So the standard is
-
not saying: "Please warn the user to check
if the other phone really has no input
-
output." So I just say pair and it pairs.
-
Yup.
Applause
-
So far that's only things that are as
-
they are in the standard, so it's not too
surprising. So the question is: Can we
-
find more bugs? Yeah. Finding bugs in
Bluetooth. Actually I didn't even want to
-
find bugs in the beginning, I just wanted
to understand how everything works. So I
-
went through the handlers and I checked
the... there's these checks of the
-
parameters, so there is a parameter check
in the beginning of each handler that
-
shows me a bit which handler it could be
according to the standard. And suddenly
-
there is a handler which does not have any
check. So there's just the missing "if"
-
somewhere. And then I compared to firmware
versions that I had and found out they
-
silently patched that already some time
between June 2nd and August 19th in 2014.
-
But they never updated older devices, so
they never shipped an .hcd-patch. So I
-
contacted Broadcom and said: "Yeah you
have a problem!" and they said "No, we
-
don't." And I said: "You really have a
problem there." And so on... And then they
-
said: "It doesn't exist." And then I
showed them more and then they said "Yeah
-
ok, but it's not compliant to the standard
what you're doing!"
-
Laughter
Applause
-
I'm sorry, my next exploit will be
standard complaint.
-
Laughter
And then we discussed a bit more and then
-
they said: "It does not affect Wi-Fi
performance." Well, in my tests it did...
-
whatever... doesn't matter. So basically
you can switch off Bluetooth on another
-
device and then Bluetooth restarts
typically depending on configuration. And
-
as Broadcom didn't tell me much about this
I started testing out things on my own. So
-
which devices actually still have a
firmware that is affected in their
-
Broadcom chip? It's quite a lot. So it's
like the iPhone 6, MacBook Pro from 2016,
-
of course my Nexus 5, Raspberry Pi 3 and
so on. And this list is really not
-
complete this is just like, I asked my
students: "Can I test your smartphone?"
-
Some of them said: "No. Are you crazy?!"
Laughter
-
And that's the list I got just during the
last weeks. And this is the one I'm going
-
to demo. I just named it BT-B-g0ne, so you
can kill the Bluetooth of annoying songs
-
or something.
Applause
-
So I need to go into the Bluetooth here,
yeah, screen-in-screen... That's great. I
-
even had a "Bluetooth is not real" and so
on. That's really great. What is going on
-
here.
D: OK.
-
J: Yeah let's go for the demo. So first we
are going to patch the Nexus 5 with our
-
funny attack and then just press enter and
now it takes a while until the the iPhone
-
is realizing like "Oops my Bluetooth is
gone." So if I'm playing music you will
-
see it faster, the music would already
stop playing. Let me just enter another
-
time. Just... Yes, and there it's gone!
Oops!
-
Applause
-
And then it appears again and so on I can
-
just do it again and again and again. And
it's actually so fast that the other
-
person could not play music, because music
also stops playing after this disconnect.
-
Yeah that's the demo. Now we were
wondering, yeah, what is actually
-
happening. So actually that the crash -
the crash is the best case. So there is a
-
handler. I call it "Handler A", because
I'm not leaking the actual problem here.
-
Broadcom didn't fix it yet. So there is
this handler which just should take, let's
-
say, two arguments or something. But it
doesn't check the parameter range and the
-
compiler likes to put one handler after
the other. And then we just go into the
-
next handler, and so we have something
like 250 functions that we can call from
-
the next handler but with wrong
parameters. So it's a bit buggy, and
-
sometimes if a function expects to get
other parameters it just crashes. But
-
otherwise we can execute functions. And on
the Nexus 5 we looked a bit more into this
-
and I found out that I can enable test
mode. So test mode should be something
-
only locally to be enabled on a phone if
you have root access to the driver and
-
then you tell the driver: "I'm now going
to test your frequencies and so on please
-
go in test mode." But I can now do this
remotely.
-
Applause
-
So I didn't bring this one as a live demo.
-
I mean I have a HackRF with me, we can do
that during Q and A, because the problem
-
is there is probably too much going on in
the spectrum here and you wouldn't see the
-
test mode starting anyway. So I'm just
doing the attack and then on the left hand
-
side, I just took a quick pause, you can
see the test mode, so that's just the
-
default test mode hopping around in all
channels. The packets now appear a bit out
-
of order because I just put them into a
queue, send them. This "???" payload is
-
the malicious payload. I just send
"test_control" and "test_activate". And
-
first they get this not_accepted. And then
after this "???" payload you can see that
-
it's accepted. And on the left hand side
you can still see that there is the test
-
mode going on, so really block things for
longer time. And then it's accepted, magic!
-
Applause
-
If you combine this with disabling
adaptive frequency hopping you can even
-
force the other device, which is also then
in test mode, to stop hopping for a while
-
and then just jam a selected frequency, so
you could also jam a selected Wi-Fi
-
frequency that this device is currently
using. And it's a combo chip, so you would
-
really be on the same antenna. We can
confirm this works on Nexus 5 and Xperia
-
Z3, because they both have to be same
BCM4339 chip. It might also work on other
-
devices with that chip. It's a bit random
to find out what is in there. You need to
-
find teardowns and on. So when finding
this bug we started developing a
-
toolchain. So Dennis added a feature for
tracepoints. You can add now a tracepoint
-
to a function which is then called once
and dumps all the registers and the stack
-
and heap. I then fed this into an
emulation framework, which is currently
-
quite slow with unicorn and radare2,
but I get a full call trace, which is very
-
nice to look at. So I have an idea what is
going on, what is changed in the memory.
-
And I currently have a student working on
a qemu/gdb set up, which is faster but
-
producing less output, just to fuzz more
efficiently. However, you get really a lot
-
of output that we weren't able to
completely analyze yet, so there's
-
probably more. Maybe tell you somewhen
later. Now you need to somehow fix that
-
bug. And that's that's really a problem,
and that's also why I didn't tell you the
-
exact payload that is causing these
issues. Because, well, the fix would be in
-
one of those .hcd-files. It would be
plaintext. It would not be signed and it
-
would just tell you directly "This handler
is vulnerable in exactly this position!"
-
and so on. The patch is just 14 bytes, but
you need to install it and then it's easy
-
to understand what it does, right? So I
had an idea: Let's do some more generic
-
fix. So what I planned to do was having a
generic filter, filtering some packets
-
like that you won't reply to, pings
connection establishments and so on, to
-
untrusted devices. And then just over
Christmas I started testing that one with
-
bigger setups, with more phones and so on.
And then I realized: OK if I throw away
-
some packets and the other device does not
expect me to throw away packets, then the
-
Bluetooth stack of a device which now
tries to connect to me is going to crash.
-
So I had the next bug! So I tried to fix
one bug. I get the next bug, you know
-
this. So I actually cannot release any
fix, because ... uh. Yeah. Because all of
-
them still cause the next bug and so on.
So how long will this bug be around?
-
Pretty long probably because there is some
devices which are no longer getting vendor
-
updates. It needs to be in the vendor
update, it needs to be this special .hcd-
-
file. And so on. I mean we can also
publish .hcd-files if needed. That's
-
possible with our framework. That's the good
news, but it will probably never be an
-
official update. And the vendor updates
will obviously leak the vulnerability. So
-
it's chicken-egg. As we found this bug
still to be present in devices that were
-
produced in 2016, we recommend you to turn
off Bluetooth - especially if you have a
-
Broadcom chipset produced before 2017.
But in general just turn it off. That's
-
probably the safest option. And we found
out that very old devices having something
-
like Bluetooth 3.0 are not vulnerable,
because that feature that we used didn't
-
exist back then. But still it's a large
number of devices having this issue.
-
So, thanks for listening.
-
Long Applause
-
Herald: And again if you have questions we
have 8 microphones in the hall. Please
-
line up at the microphones and you can ask
your questions.
-
The Signal Angel has the first
question from the Internet.
-
Signal Angel: Yes some of the Internet
asked if you can guess the Bluetooth MAC
-
address from the wifi MAC address of a device.
Jiska: Yes. So if I go into... Can we
-
switch the camera on again? On my magic
box here. Is that possible? Yes. So
-
actually, if you go to the "Settings",
"About", and then you will see that the
-
WiFi and Bluetooth MAC address, they are
just off by one.
-
Laughter and applause
Dennis: So yeah. You have to note however
-
that this is not the case with every
phone. So usually I think new phones
-
actually try to randomize their Wi-Fi MAC
address to be not traceable anymore. Not
-
sure which devices do that. I think the
Nexus 6P does that so the first part will
-
be the same, because it specifies which
vendor this chip was made from. But then,
-
the lower and least significant bits will
change. So it's sometimes possible,
-
sometimes not. Yeah. I think that's the
answer to this question.
-
Herald: OK. The next question was from the
microphone 8 at the very end of the hall.
-
Eight: Hello. Thanks for your talk. I was
-
wondering in your second demo, you showed
us how you connect to a device, just using
-
the MAC address and this device was not
advertising his name. How do you find a
-
MAC address, if it's not advertising?
Dennis: Yeah. So there are ways to find
-
out the MAC address of devices which are
nearby you. So for example if your device
-
has Bluetooth turned on but it's not
discoverable at the moment, but you're
-
listening to music on your headphones or
if you have a smartwatch connected or
-
any other Bluetooth device connected, then
you will certainly send Bluetooth traffic
-
and you can sniff that from the air. For
example with a software-defined radio or
-
an Ubertooth. And so in the talk we
mentioned and we also have a link to this
-
in the slide, I guess it was here,
"Bluetooth smells like chicken". Michael
-
Ossman and Dominic Spill, they actually
explained very detailed how you can then
-
infer the MAC address from those packets
you sniffed. And, yeah, it's doable. It's
-
not as easy as with Wi-Fi but it's
certainly possible.
-
Eight: Thank you.
Herald: Okay. The next question was at
-
Microphone number one.
One: Thanks for your talk and demos. The
-
question is, does this firmware have any
mitigations against exploitation? And if
-
we imagine that it has, would it help
against such bugs?
-
Dennis: So. There's no, like real address
randomization, kind of the obvious way,
-
because there's... Most of the things are
actually global offsets inside the
-
firmware. So everything is at fixed
addresses, like you would use global
-
variables all over. There's also the RAM,
it's actually executable, so you can
-
execute on the stack, you can execute on
the heap, everywhere. So there's no real
-
mitigations for such a exploitation. It's
like, I don't think even the newer ones
-
have that sort of, and the Nexus 5
obviously.
-
Jiska: And another thing that really helps
us. So LMP has a version_request,
-
version_response, which is always sent. So
I can ask a device actually: Do you have a
-
vulnerable firmware and which version? And
then I can run exactly the exploit. And
-
the firmware, I mean, the firmware is
standard and I can just run the addresses
-
that I know for a certain firmware.
Herald: Okay. The next question was at
-
microphone number two. Then again number
one, three and five.
-
Two: Hi. Thanks for the work especially
for BT-B-g0ne since like it's the TV-B-
-
Gone. And I'm not sure of which kind of
iPhone that works, because you had a slide
-
about iPhone up until 6, and then you had
a slide that saying if the chip is older
-
than 2017. So does that work with the last
phones as well?
-
Jiska: Only up to iPhone 6 that was used
was the latest I could get. So if you have
-
an iPhone 8 or something, our attack does
not work.
-
Two: So you're going to work on it?
Because a lot of people are playing very
-
bad music and have new phones.
Laughter
-
Jiska: You mean the attack. The attack is
not working on iPhone 6, but the general
-
framework like patching .hcd-files or
changing the firmware will obviously work
-
on any Broadcom chip.
Two: Okay, thanks.
-
Dennis: Broadcom actually uses this
mechanism for all their chips, all their
-
Bluetooth chips, so you can use this
framework for every Broadcom chip, every
-
device that has a Broadcom chip. You only
need to do the reverse engineering, as to
-
get like the real addresses and offsets
inside the firmware to do meaningful
-
patches.
Jiska: But for this you always need to be,
-
to have a rooted device. You need root
access on the device to run our patching
-
framework.
Two: Okay. Thanks.
-
Herald: Okay. Now the question at
microphone number one.
-
One: Do you have a list of vulnerable
chipsets? So I can check if my phone is
-
vulnerable if it's not like in those
slides.
-
Jiska: Yeah, but it's very incomplete. So
I also have that, the version numbers and
-
subversion numbers of those phones. But
just consider the time range. So if your
-
smartphone does Bluetooth 4.0 to 4.2 and
it has a Broadcom chip then it's very
-
likely to be vulnerable.
Herald: Okay, now the question from
-
microphone number three.
Three: Thank you for the codes and the
-
talk. Quick question, so have you looked
at a car Bluetooth? And if not, are you
-
thinking about it?
Dennis: So I actually used this tool. As I
-
mentioned previously, we are also able to
test other vulnerabilities, for example
-
this fixed coordinate invalid curve
attack. And so I used my tool to actually
-
check if a car radio was vulnerable to
this fixed coordinate invalid curve attack
-
that was released this summer. So it's
basically patched since half a year but
-
the car was still vulnerable to this. So
the framework is basically usable to test
-
car radios as well, but I haven't like
specifically looked into a car radio.
-
Three: Thank you.
Herald: Okay. Now a question from
-
Microphone number five. Then we take a
question from the Internet and microphone
-
number six.
Five: What is the attack surface exposed
-
by your exploits? What's the worst case?
Could you manipulate memory or something?
-
Jiska: Worst case it's hard to estimate. I
mean we can change some memory addresses
-
at least in the Nexus 5. And for each
smartphone there are other functions by
-
the compiler put there. So to really know
what is happening, we would now need to
-
analyze like really tons of firmwares and
check what is in there and do some
-
fuzzing. We already found out that some
things only happen if you combine multiple
-
packets and so on. So it's really hard to
estimate what is the worst case. So the
-
very worst case would be, so to say, that
you can run arbitrary code in the
-
Bluetooth, in the Bluetooth firmware
itself, and then the next worst case would
-
be if there would be another vulnerability
in the driver, that you could escape
-
the firmware. So that would be the next
step. But that really requires an exploit
-
chain. So the very worst case would be
something similar. So there has been
-
vulnerabilities in the Wi-Fi part of
Broadcom chips where you had the
-
possibility to really run an exploit chain
which then rooted a device in the end. But
-
it's hard to estimate if you can do it
with this or not.
-
Herald: OK. Now the question from the
Internet please.
-
Internet: Do you know if any older but
still supported devices like old MacBooks
-
are patched and can you actually detect
this in any way other than a chip crash?
-
Jiska: Not really, so we can try to not
crash the chip by first checking if it is
-
sending appropriate answers, but typically
the really only thing to be sure is that
-
it crashes. So that so far is the only
way, because I mean obviously, if Broadcom
-
would tell "the following chips are
vulnerable", which they didn't so far,
-
because that's also to protect themselves
probably, then you could be sure. But yeah
-
as of now that's the only way to check it.
Herald: Thank you. Now the question from
-
microphone number six please.
Six: Yeah. Would it be possible to
-
increase the Bluetooth radio transmission
power by patching the firmware? So that
-
Bluetooth works across entire
buildings and not only in a single room?
-
Dennis: Yeah. So the thing is, we are
actually now patching the firmware of the
-
chip, and the firmware does like all the
the link layer stuff of Bluetooth. The
-
real physical part is probably done in
another component inside the chip which
-
may be running another kind of small real-
time firmware and we haven't found that
-
yet. We are still looking for it because
that must be in there somewhere, like that
-
Bluetooth modem and maybe we can actually
change the settings for this modem. I
-
don't think it will be too drastical. But
maybe if you're in different areas of the
-
world and like your Bluetooth has
different strengths in different areas of
-
the world, you can maybe manipulate that.
But we haven't found it yet.
-
Six: OK. Thank you.
Herald: Okay. Next question is coming from
-
microphone number four.
Four: Does the Bluetooth chipset have
-
access to system RAM?
Dennis: Sorry I didn't get the last word.
-
Jiska: The system rights or what do you
mean?
-
Four: The system RAM, memory.
Dennis: You mean the memory of the main
-
processor like where Android or iOS is
running on?
-
Four: Yes.
Dennis: No it's not like as with Wi-Fi
-
where you have direct memory access. But
Bluetooth, the HCI interface is the only
-
interface between those two processors.
And this is usually done over either USB
-
or in the Nexus 5 is actually UART.
Herald: Next question is coming from
-
microphone number three.
Three: Many thanks for the enlightening
-
and scary talk. I missed a little bit of
the beginning maybe that question was
-
inside there. Did you or do you considered
to disclose this vulnerability for example
-
to BSI (Bundesamt für Sicherheit in der
Informationstechnik)? As I would consider
-
their obligation to inform general public
like put a note on their website saying:
-
"Look, if you're running a certain
smartphone you're vulnerable to a certain
-
attack!" And that would put much more
stress on the vendors to really look into
-
this.
Jiska: Yeah that sounds like a good
-
option. So far we're, so we asked Broadcom
when we can publish things and at least
-
they agreed that it's no problem to
publish it in summer, then it would be
-
public for everyone. But yeah, BSI would
also be a nice option.
-
Three: Thank you.
-
Herald: OK. Is there another question
from the Internet?
-
…
-
Please switch on the
microphone for the Internet.
-
Internet: Hello? Hi. So do you know if any
devices have been patched yet, which have
-
not been released after 2017, or are there
no rolled out patches?
-
Jiska: I don't think so. So, it took
Broadcom two months to actually confirm
-
that there is this vulnerability. So on
December 3rd they said, ooops it really
-
exists. And then on December 9th, they
were like: "Ooh, do you really plan to do
-
that talk here?!"
Laughter
-
And I did the most recent iOS update on
the iPhone 6 that I just showed you. And
-
this one is still valuable. I think it
takes some time for testing. So I would
-
say the first patches will come out maybe
in 1, 2 months, but we don't know.
-
Herald: Okay. One last quick question from
microphone number one.
-
One: So is it … do you think it is
possible to trace back when was this
-
vulnerability introduced, so we can go
back and try to hack old devices that
-
probably have the same firmware or
firmware vulnerability? Because they
-
should be backward compatible, right? So
if the same handler is implemented I
-
know in 2012 first and for the first time
then uh...
-
Jiska: Yeah.
One: Probably the devices can be narrowed
-
down, right?
Jiska: So at least.. so the Nexus 5 has a
-
firmware from 2012 actually. So somewhere,
so the June 2nd is when it still existed
-
in 2014. I don't know. So in each firmware
there is a build date and I would then
-
need to extract the firmware of vulnerable
devices and so on, so it's a long process,
-
but at least the vulnerability was there
for multiple years.
-
Herald: Okay now give please a huge round
of applause for Jiska Classen
-
and Dennis Mantz for their talk.
-
Applause
-
Dennis: Thank you!
Applause
-
35C3 outro music
-
subtitles created by c3subtitles.de
in the year 2019. Join, and help us!