< Return to Video

35C3 - Dissecting Broadcom Bluetooth

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

more » « less
Video Language:
English
Duration:
43:03

English subtitles

Revisions