*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!