Return to Video

34C3 - Doping your Fitbit

  • 0:14 - 0:19
    Herald Angel: This talk is going to be
    doping your Fitbit. It's gonna be held by
  • 0:19 - 0:27
    jiska and daniel. In case you have been to
    any of the smaller CCC events in the past,
  • 0:27 - 0:33
    I think 3 maybe 4 years, you might know
    jiska from the, that you're usually where
  • 0:33 - 0:39
    there is sewing machines. And actually
    double plus for both of them, because for
  • 0:39 - 0:43
    daniel it's actually the second shift
    today as a speaker, which by itself
  • 0:43 - 0:54
    probably is stressful. Getting back to the
    smaller events. On the MRMCD this year
  • 0:54 - 0:57
    they had sort of the first session on the
    same topic, so if you missed that you
  • 0:57 - 1:01
    might want to check out the recording of
    this. There they spoke about decoding the
  • 1:01 - 1:06
    messages. This time they're gonna talk
    about the actual firmware of the fitbits.
  • 1:06 - 1:14
    And with that I give the stage to you.
    applause
  • 1:14 - 1:23
    DanielAW: Thank you.
    jiska: Welcome to our talk on doping your
  • 1:23 - 1:28
    fitbit. We will show you how to modify the
    firmware so that you don't have to
  • 1:28 - 1:32
    anything but, well no sports as every
    nerd...
  • 1:32 - 1:36
    laughter
    j: Our motivation was when we started
  • 1:36 - 1:44
    taking fitness trackers, that most of them
    are not encrypting locally. So you will
  • 1:44 - 1:51
    always have a chance to get the data from
    users, which is not nice for privacy. And
  • 1:51 - 1:56
    most apps require that you upload your
    data into the cloud. So that's again bad
  • 1:56 - 2:03
    for privacy. If you look at fitbit they
    are one of the market leaders, so that's
  • 2:03 - 2:07
    one thing why we hacked them. And the
    other thing is that when we compared
  • 2:07 - 2:14
    vendors, that they had quite reasonable
    security, which is similar to many IoT
  • 2:14 - 2:19
    systems. So, what we show today will apply
    to other systems too. And their security
  • 2:19 - 2:26
    model is nice, but requires sharing you
    data to them. So, take the security, but
  • 2:26 - 2:32
    get your data would be a nice thing. So
    therefore we hacked them. I will first
  • 2:32 - 2:38
    explain how the system works in general,
    which messages are exchanged, and then go
  • 2:38 - 2:46
    to more technical details.The trackers
    have a key installed which is symmetric
  • 2:46 - 2:52
    and it's enrolled during factory rollout.
    So, it's already on the tracker when you
  • 2:52 - 2:58
    buy it. And it's used for end-to-end
    encryption with the server. So, the system
  • 2:58 - 3:02
    is as secure as end-to-end encryption. As
    soon as you have a flaw of course no
  • 3:02 - 3:09
    longer, but that's the idea. And the
    tracker only has Bluetooth LE, so you need
  • 3:09 - 3:12
    the smartphone application which is
    forwarding the traffic. The local
  • 3:12 - 3:18
    connection is now very secure, but it
    doesn't matter that much because of the
  • 3:18 - 3:22
    end-to-end encryption. And now the thing
    is, can we break the end-to-end
  • 3:22 - 3:28
    encryption? Well, yes we can. The end-to-
    end encryption is only used for the recent
  • 3:28 - 3:33
    trackers, so models before 2015 were not
    always using encryption and we could look
  • 3:33 - 3:39
    a bit into the protocol. And there has
    been a memory readout attack which was not
  • 3:39 - 3:44
    patched for trackers until recently. So if
    you buy a tracker now you have a good
  • 3:44 - 3:49
    chance that you didn't patch the software
    so far yourself or someone else didn't do
  • 3:49 - 3:57
    it so far and you can do memory readout.
    And all these things are somewhat
  • 3:57 - 4:02
    encryption flaws or connected to encryption.
    And I'm now going to show you how you
  • 4:02 - 4:09
    can now break the encryption on the
    tracker and get your data. If you have the
  • 4:09 - 4:14
    original smartphone app and a tracker, you
    have two steps in the beginning. So you
  • 4:14 - 4:19
    log in into the app, which is, if you make
    you own app, is not necessarily required
  • 4:19 - 4:25
    and you do some local pairing, which
    anyone can do with a tracker.
  • 4:25 - 4:29
    And then there's an interesting part,
    which is remote association, and in this
  • 4:29 - 4:33
    remote association you prove that you are
    physically owning the tracker, for example
  • 4:33 - 4:40
    by entering a PIN. And as soon as you have
    this proof you can get authentication
  • 4:40 - 4:45
    credentials from the server and use these
    authentication credentials to run
  • 4:45 - 4:49
    authenticated commands - and that's now
    the part that is getting interesting
  • 4:49 - 4:54
    because these authenticated commands you
    can execute them as often as you want as
  • 4:54 - 4:59
    soon as you have those authentication
    credentials and they are valid forever
  • 4:59 - 5:06
    because they are bound to the device key.
    So, another question is first of all how
  • 5:06 - 5:12
    you get these authentication credentials.
    And therefore you can associate your
  • 5:12 - 5:17
    tracker; there are some flaws in it, so
    you need to prove that you are physically
  • 5:17 - 5:23
    present, but well, how do you do this? I
    mean, the first part is of course if you
  • 5:23 - 5:30
    have a display then you have a PIN. The
    PIN is displayed on the tracker, and then
  • 5:30 - 5:34
    you have the smartphone app where you
    enter the PIN. The PIN is transferred from
  • 5:34 - 5:38
    the tracker end-to-end encrypted to the
    server, you compare it on the server with
  • 5:38 - 5:42
    the thing that you entered in the app.
    That's okay-ish, but then there are also
  • 5:42 - 5:46
    those trackers that don't have a display -
    you just tap them and the tapping
  • 5:46 - 5:52
    confirmation is a wireless frame which you
    can easily replay. And there is no
  • 5:52 - 5:58
    confirmation of freshness of either of
    those, so you can replay any sniffed
  • 5:58 - 6:05
    remote association process. And there are
    those old plain-text trackers and they
  • 6:05 - 6:10
    have the serial number printed on the
    packing, and you can just use the serial
  • 6:10 - 6:17
    number and craft a valid packet from this
    and do the association if you want. And
  • 6:17 - 6:21
    since those association credentials are
    valid forever - well, you just use them as
  • 6:21 - 6:25
    soon as you have them - you could even
    resell your tracker and use them again,
  • 6:25 - 6:31
    and sniff someone else's data.
    The first thing that we used to break
  • 6:31 - 6:36
    encryption is an authenticated memory
    readout. It was already found by Martin
  • 6:36 - 6:42
    before on the Charge HR firmware. He
    compared, actually, a firmware update and
  • 6:42 - 6:49
    found that they removed the command, and
    Fitbit didn't remove the command on the
  • 6:49 - 6:55
    Fitbit One and Flex until October, so you
    could still use this memory readout on the
  • 6:55 - 7:01
    older trackers and you could just enter
    any memory address and length and get all
  • 7:01 - 7:07
    the data that is located at this address.
    This includes the encryption keys, so with
  • 7:07 - 7:13
    this encryption key you can then fake any
    encrypted packet to the tracker or from
  • 7:13 - 7:20
    the tracker including the dumps which
    contain the activity data or even
  • 7:20 - 7:25
    firmware.
    And then you might ask yourself - well,
  • 7:25 - 7:29
    why did they do this, the memory readout?
    Obviously this was not patched, but they
  • 7:29 - 7:35
    still have authentication and you need
    authentication for so-called live mode,
  • 7:35 - 7:40
    for example if you have a heart rate
    sensor on the Fitbit, then you don't want
  • 7:40 - 7:45
    to send each time your current heartrate
    to the server, let the server decrypt your
  • 7:45 - 7:49
    heartrate, and so on because then it would
    lag a lot and you would have a high load
  • 7:49 - 7:56
    on the server. So what they did was more
    where you can do some strange closing of
  • 7:56 - 8:00
    airlink, enable some other Bluetooth
    handles, so it's a bit hidden, so nobody
  • 8:00 - 8:05
    didn't find it so far, and then you get a
    very nice thing, which is this live data.
  • 8:05 - 8:12
    And it is not encrypted and it's a summary
    of your current data. So, two things about
  • 8:12 - 8:16
    this - first of all, you can sniff it,
    it's plain text, everyone could sniff it.
  • 8:16 - 8:23
    And everyone having authentication
    credentials can enable it. And, well,
  • 8:23 - 8:28
    Fitbit fixed this on their last Firmware
    update in the sense of that you can
  • 8:28 - 8:33
    disable the live mode if you wish to, but
    you can still use it on any tracker where
  • 8:33 - 8:43
    you didn't disable it manually and it's
    present in the most recent Ionic smartwatch.
  • 8:43 - 8:47
    Now Daniel is going to tell you more about
    the firmware and hardware access.
  • 8:47 - 8:49
    D: Alright. Thank you.
  • 8:49 - 8:54
    For or some of the stuff which we already
    told you, and also the dynamic debugging, we
  • 8:54 - 9:00
    want to have some access to the
    actual hardware, so the tracker itself.
  • 9:00 - 9:08
    But first of all let's look at some
    schematic on how the PCB is structured. So
  • 9:08 - 9:13
    we have the main system on a chip, which
    is from STM in our case. Here it's based
  • 9:13 - 9:24
    on an Cortex M3, and we also have of course
    BLE chip, which is used for communication
  • 9:24 - 9:29
    with the smartphone app. And we also have
    an accelerometer which detects your steps.
  • 9:29 - 9:35
    And everything is connected via bus. And
    most interestingly, we also know for some
  • 9:35 - 9:40
    of the software which runs in the
    firmware, basically which library they
  • 9:40 - 9:45
    used. So for example for encryption, we
    know that they use LibTomCrypt, and for
  • 9:45 - 9:50
    BLE we at least know that the LibBLEShield
    is very similar to what they use in the
  • 9:50 - 9:58
    firmware. So this really helped us in
    reverse engineering. So this is what the
  • 9:58 - 10:05
    PCB looks like if you tear it apart and
    remove it from its casing basically. We
  • 10:05 - 10:12
    already see that there are lots and lots
    of testing points, and now this time we
  • 10:12 - 10:19
    figure out what testing points we need to
    connect the debugger. And so we figured
  • 10:19 - 10:26
    out, or some other guys already figured
    out that you need those four. So,
  • 10:26 - 10:32
    depending on what protocol you want to use
    for your debugger you need various amounts
  • 10:32 - 10:41
    of testing pins, and herefore in our case
    we use SWD, so we just need four pins.
  • 10:41 - 10:47
    Namely testing point 8, 9, 10, and then
    ground pin. And, so you can also see that
  • 10:47 - 10:53
    we use just the ground pin from the
    battery which we removed previously, and
  • 10:53 - 10:58
    on the right hand side is just the
    connector switch you can use to connect
  • 10:58 - 11:05
    it, the Fitbit, to your power supply. And
    so with this we can already dump the
  • 11:05 - 11:10
    firmware, and we can also modify the
    stored data. And now that we have the
  • 11:10 - 11:15
    firmware, let's have a closer look into
    it. By the way, this on the right hand
  • 11:15 - 11:22
    side is our test setup It may look kind of
    crude, but it worked.
  • 11:22 - 11:29
    And, so yeah, the memory layout is
    basically split up in 3 parts. We have a
  • 11:29 - 11:34
    flash which contains the firmware code,
    and EPROM which contains the data which
  • 11:34 - 11:39
    should survive an empty battery, so for
    example your fitness data. And also an
  • 11:39 - 11:44
    SRAM which is used for, or which provides
    some space for firmware variables. So if
  • 11:44 - 11:51
    we look into the flash for example in a
    more detail, we see that there are
  • 11:51 - 12:01
    actually 2 independent firmwares or stuff
    which runs on that. So we have a part
  • 12:01 - 12:06
    which is called BSL, and a part which is
    called APP. And the reason for that is you
  • 12:06 - 12:10
    always want to have some fail safe mode
    when you update the firmware. So jiska
  • 12:10 - 12:17
    will talk about more this... about this in
    more depth, in later slides, but for now
  • 12:17 - 12:21
    just keep in mind that there are two
    parts. And on the EPROM we have apart
  • 12:21 - 12:24
    from this fitness data, we also have
    everything we need for encryption, so we
  • 12:24 - 12:28
    have our serial number. We have an
    encryption key and we have even a switch
  • 12:28 - 12:35
    which you can use to completely disable
    encryption.
  • 12:35 - 12:41
    So what we also wanted to do is enabling
    GDB access, so to have dynamic debugging
  • 12:41 - 12:47
    support. But we discovered this in case
    you set everything up and you connect GDB
  • 12:47 - 12:53
    to it and then you hit run, your GDB
    connection will just reset after a certain
  • 12:53 - 12:59
    point when the firmware boots up. And the
    problem is that the firmware actually
  • 12:59 - 13:04
    disables these GPIO ports during the
    bootup. So it uses this for other stuff,
  • 13:04 - 13:09
    which is bad for us. And so we decided, so
    what can we do to reenable them. Yeah,
  • 13:09 - 13:17
    just we modify the firmware. And so in our
    group we already developed this nexmon
  • 13:17 - 13:24
    framework which we use previously to
    binary patch some wifi firmwares, and now
  • 13:24 - 13:31
    we just adapted it - [ironically:] just adapted it - for
    the Fitbit firmware. And now we are able
  • 13:31 - 13:38
    to modify the firmware in any way we want,
    and of course we can just reset the GPIO
  • 13:38 - 13:46
    pins after the bootup to be capable of
    debugging. So now we have basically GDB
  • 13:46 - 13:52
    access, can set breakpoints and memory
    watchpoints. Which really helped us in
  • 13:52 - 13:56
    reverse engineering.
    So now jiska will tell you more about
  • 13:56 - 14:01
    wireless firmware flashing.
    j: You might have seen our nice setup with
  • 14:01 - 14:06
    the open Fitbit, but it's quite hard to
    open a Fitbit. So it's not super hard, but
  • 14:06 - 14:11
    it's hard to use it again after it's
    opened. So the idea is now to wirelessly
  • 14:11 - 14:15
    flash your firmware, which needs some more
    reverse engineering in the firmware of
  • 14:15 - 14:23
    this process, and then we were able to do
    it. The update process is a bit
  • 14:23 - 14:30
    complicated, so in each activity data that
    you transmit to the server, you include
  • 14:30 - 14:35
    the firmware version of the tracker. And
    the server then knows, well you have maybe
  • 14:35 - 14:40
    an outdated firmware and in this case in
    the app there is shown that there is a new
  • 14:40 - 14:44
    firmware update available. But it's not
    flashed onto the tracker until the user is
  • 14:44 - 14:52
    actually tapping this update in the app.
    But, this is not really a security feature, so
  • 14:52 - 14:57
    anyone could trigger a firmware update.
    It's not any user interaction required
  • 14:57 - 15:03
    normally. As soon as the update is started
    you get a microdump from the tracker,
  • 15:03 - 15:08
    which contains tracker metadata including
    the serial number and the firmware version
  • 15:08 - 15:12
    once again, which is attached to a
    firmware request. And the firmware request
  • 15:12 - 15:18
    is then being replied from the server and
    contains the BSL and APP firmware parts
  • 15:18 - 15:25
    which Daniel just showed you. The firmware
    starts then with the BSL flashing. The BSL
  • 15:25 - 15:32
    is first validated, then it's written to
    the flash and then you reboot into this
  • 15:32 - 15:38
    BSL part. Same thing then for the APP
    part, which is again validated, written to
  • 15:38 - 15:42
    flash, and then there's a reboot into the
    APP. And in the APP you have the normal
  • 15:42 - 15:50
    functionality back again.
    This update format ensures that you are
  • 15:50 - 15:55
    flashing the correct firmware in the
    correct order to the tracker. So each
  • 15:55 - 16:00
    chunk in the firmware is starting in the
    actual tracker model. So each of them has
  • 16:00 - 16:04
    this hex code depending on the tracker
    model. Then you have a chunk which is
  • 16:04 - 16:09
    marked either as BSL, APP, or the reboot
    action. And depending on which of these
  • 16:09 - 16:16
    actions you have either some zero bytes or
    the actual content. And you have also a
  • 16:16 - 16:25
    size limit of something like 64 kilobytes,
    depending on the tracker. So you just need
  • 16:25 - 16:32
    to attach these things together. So if you
    have an APP firmware update it contains 3
  • 16:32 - 16:39
    chunks, then 1 empty chunk, and 1 reboot
    chunk. And all these chunks are attached
  • 16:39 - 16:45
    to each other and then there's another
    header. The header's having the encryption
  • 16:45 - 16:52
    options and if it's encrypted a nonce and
    the end has another CRC or if it's
  • 16:52 - 17:00
    encrypted you have a CMAC tag. Now you
    would say - well, you discovered how the
  • 17:00 - 17:05
    firmware update works and that's nice, but
    if you do it like this you will still get
  • 17:05 - 17:07
    some errors.
    So, the address range is of course
  • 17:07 - 17:15
    checked, you could pass this address range
    check if you would flash one more round
  • 17:15 - 17:22
    and then disable this address range check.
    But okay, then you have a bitflip and CRC
  • 17:22 - 17:28
    somewhere in the middle of the firmware,
    where you need to flip a bit, calculate
  • 17:28 - 17:32
    another CRC, include it into the firmware,
    because otherwise the firmware that you
  • 17:32 - 17:40
    flash will not boot and show you firmware
    version 0.0 in all activity dumps which is
  • 17:40 - 17:44
    not that nice, so you cannot simply
    replace a string in the firmware for
  • 17:44 - 17:49
    example without this being to happen.
    And now Daniel is going to tell you how
  • 17:49 - 17:58
    the encryption on top of all this works.
    D: The problem is, so we now know how we
  • 17:58 - 18:06
    do firmware encryption in plaintext mode,
    but most of the new trackers basically
  • 18:06 - 18:12
    have encryption enabeled by default. So
    what we now need to do is to just build an
  • 18:12 - 18:19
    encrypted firmware update. What do we need
    for that? Older models of the trackers use
  • 18:19 - 18:27
    XTEA for encryption whereas newer models
    use AES. For this you need basically three
  • 18:27 - 18:34
    things: 2 byte nonce which is contained in
    each and every dump you get, a 128 bit encryption
  • 18:34 - 18:40
    key which you can get with the
    aforementioned memory readout attack and
  • 18:40 - 18:49
    also an 8 byte MAC which you can just
    calculate. For this they use LibTomCrypt
  • 18:49 - 18:55
    which is a C-library, which we told you
    before, but you can also use the
  • 18:55 - 19:01
    spongycastle library which is in Java.
    This also contains every function you
  • 19:01 - 19:08
    need. Now we know everything we need. We
    know how the communication works, we know
  • 19:08 - 19:14
    how the firmware update is structured and
    we know how to encrypt it properly. Let's
  • 19:14 - 19:19
    put it all together.
    Here are 6 steps which you need to do when
  • 19:19 - 19:28
    you want to build your own modified Fitbit
    flags firmware. First you get your
  • 19:28 - 19:35
    symmetric key, then you get a plaintext
    dump of your firmware binary. You transfer
  • 19:35 - 19:41
    everything to a notebook or any PC
    basically which you can then use to run
  • 19:41 - 19:49
    our nexmon framework and then you modify
    the firmware in any way we want. For the
  • 19:49 - 19:58
    first and last two steps we have an Android app.
    You can see the URL and the source code
  • 19:58 - 20:04
    above. And for the nexmon framework, the
    adapted version, we have also another repo.
  • 20:04 - 20:08
    The last two steps are: transfer the
  • 20:08 - 20:12
    firmware back to your smartphone,
    reencrypt it and flash your tracker with
  • 20:12 - 20:19
    it. Of course we did this before and now
    we can show you a nice demo of what you
  • 20:19 - 20:26
    can do with it. Of course you want to
    modify your fitness tracker in an
  • 20:26 - 20:33
    interesting fashion. So for example we
    just modified it so that each and every
  • 20:33 - 20:45
    step gets multiplied by 100. Here you can
    see: I shake the Fitbit and each shake
  • 20:45 - 20:55
    creates 100 steps.
    applause
  • 20:55 - 21:00
    And maybe it is good to say that this does
    not work with the latest firmware update.
  • 21:00 - 21:07
    It says firmware update is necessary. But
    this is because we told them that this is
  • 21:07 - 21:18
    wrong. So this October update which Jiska
    mentioned came out after our research.
  • 21:27 - 21:34
    J: These modifications, you can apply them
    on a Fitbit 1, Flex or Charge HR. For the
  • 21:34 - 21:41
    1 and Flex the firmware update is not that
    far ago so you have high chances to modify
  • 21:41 - 21:45
    your tracker if you now buy one that is in
    original packing or if you just didn't
  • 21:45 - 21:52
    update yours because it was lying around.
    For the live mode it is even nicer because
  • 21:52 - 21:56
    live mode is there on all trackers so if
    you are happy with the data you get in
  • 21:56 - 22:01
    live mode you can just disable the
    internet connection of your tracker and
  • 22:01 - 22:11
    extract all your data with this.
    To sum up our task: Go out and flash your
  • 22:11 - 22:21
    neighbor's device, keep control of your
    own data, and run any code on your Fitbit.
  • 22:21 - 22:27
    applause
  • 22:27 - 22:49
    subtitles created by c3subtitles.de
    in the year 2017. Join, and help us!
Title:
34C3 - Doping your Fitbit
Description:

more » « less
Video Language:
English
Duration:
22:49

English subtitles

Revisions Compare revisions