YouTube

Got a YouTube account?

New: enable viewer-created translations and captions on your YouTube channel!

English subtitles

← 34C3 - Doping your Fitbit

Get Embed Code
1 Language

Showing Revision 5 created 01/03/2020 by C3Subtitles.

  1. Herald Angel: This talk is going to be
    doping your Fitbit. It's gonna be held by
  2. jiska and daniel. In case you have been to
    any of the smaller CCC events in the past,
  3. I think 3 maybe 4 years, you might know
    jiska from the, that you're usually where
  4. there is sewing machines. And actually
    double plus for both of them, because for
  5. daniel it's actually the second shift
    today as a speaker, which by itself
  6. probably is stressful. Getting back to the
    smaller events. On the MRMCD this year
  7. they had sort of the first session on the
    same topic, so if you missed that you
  8. might want to check out the recording of
    this. There they spoke about decoding the
  9. messages. This time they're gonna talk
    about the actual firmware of the fitbits.
  10. And with that I give the stage to you.
    applause
  11. DanielAW: Thank you.
    jiska: Welcome to our talk on doping your
  12. fitbit. We will show you how to modify the
    firmware so that you don't have to
  13. anything but, well no sports as every
    nerd...
  14. laughter
    j: Our motivation was when we started
  15. taking fitness trackers, that most of them
    are not encrypting locally. So you will
  16. always have a chance to get the data from
    users, which is not nice for privacy. And
  17. most apps require that you upload your
    data into the cloud. So that's again bad
  18. for privacy. If you look at fitbit they
    are one of the market leaders, so that's
  19. one thing why we hacked them. And the
    other thing is that when we compared
  20. vendors, that they had quite reasonable
    security, which is similar to many IoT
  21. systems. So, what we show today will apply
    to other systems too. And their security
  22. model is nice, but requires sharing you
    data to them. So, take the security, but
  23. get your data would be a nice thing. So
    therefore we hacked them. I will first
  24. explain how the system works in general,
    which messages are exchanged, and then go
  25. to more technical details.The trackers
    have a key installed which is symmetric
  26. and it's enrolled during factory rollout.
    So, it's already on the tracker when you
  27. buy it. And it's used for end-to-end
    encryption with the server. So, the system
  28. is as secure as end-to-end encryption. As
    soon as you have a flaw of course no
  29. longer, but that's the idea. And the
    tracker only has Bluetooth LE, so you need
  30. the smartphone application which is
    forwarding the traffic. The local
  31. connection is now very secure, but it
    doesn't matter that much because of the
  32. end-to-end encryption. And now the thing
    is, can we break the end-to-end
  33. encryption? Well, yes we can. The end-to-
    end encryption is only used for the recent
  34. trackers, so models before 2015 were not
    always using encryption and we could look
  35. a bit into the protocol. And there has
    been a memory readout attack which was not
  36. patched for trackers until recently. So if
    you buy a tracker now you have a good
  37. chance that you didn't patch the software
    so far yourself or someone else didn't do
  38. it so far and you can do memory readout.
    And all these things are somewhat
  39. encryption flaws or connected to encryption.
    And I'm now going to show you how you
  40. can now break the encryption on the
    tracker and get your data. If you have the
  41. original smartphone app and a tracker, you
    have two steps in the beginning. So you
  42. log in into the app, which is, if you make
    you own app, is not necessarily required
  43. and you do some local pairing, which
    anyone can do with a tracker.
  44. And then there's an interesting part,
    which is remote association, and in this
  45. remote association you prove that you are
    physically owning the tracker, for example
  46. by entering a PIN. And as soon as you have
    this proof you can get authentication
  47. credentials from the server and use these
    authentication credentials to run
  48. authenticated commands - and that's now
    the part that is getting interesting
  49. because these authenticated commands you
    can execute them as often as you want as
  50. soon as you have those authentication
    credentials and they are valid forever
  51. because they are bound to the device key.
    So, another question is first of all how
  52. you get these authentication credentials.
    And therefore you can associate your
  53. tracker; there are some flaws in it, so
    you need to prove that you are physically
  54. present, but well, how do you do this? I
    mean, the first part is of course if you
  55. have a display then you have a PIN. The
    PIN is displayed on the tracker, and then
  56. you have the smartphone app where you
    enter the PIN. The PIN is transferred from
  57. the tracker end-to-end encrypted to the
    server, you compare it on the server with
  58. the thing that you entered in the app.
    That's okay-ish, but then there are also
  59. those trackers that don't have a display -
    you just tap them and the tapping
  60. confirmation is a wireless frame which you
    can easily replay. And there is no
  61. confirmation of freshness of either of
    those, so you can replay any sniffed
  62. remote association process. And there are
    those old plain-text trackers and they
  63. have the serial number printed on the
    packing, and you can just use the serial
  64. number and craft a valid packet from this
    and do the association if you want. And
  65. since those association credentials are
    valid forever - well, you just use them as
  66. soon as you have them - you could even
    resell your tracker and use them again,
  67. and sniff someone else's data.
    The first thing that we used to break
  68. encryption is an authenticated memory
    readout. It was already found by Martin
  69. before on the Charge HR firmware. He
    compared, actually, a firmware update and
  70. found that they removed the command, and
    Fitbit didn't remove the command on the
  71. Fitbit One and Flex until October, so you
    could still use this memory readout on the
  72. older trackers and you could just enter
    any memory address and length and get all
  73. the data that is located at this address.
    This includes the encryption keys, so with
  74. this encryption key you can then fake any
    encrypted packet to the tracker or from
  75. the tracker including the dumps which
    contain the activity data or even
  76. firmware.
    And then you might ask yourself - well,
  77. why did they do this, the memory readout?
    Obviously this was not patched, but they
  78. still have authentication and you need
    authentication for so-called live mode,
  79. for example if you have a heart rate
    sensor on the Fitbit, then you don't want
  80. to send each time your current heartrate
    to the server, let the server decrypt your
  81. heartrate, and so on because then it would
    lag a lot and you would have a high load
  82. on the server. So what they did was more
    where you can do some strange closing of
  83. airlink, enable some other Bluetooth
    handles, so it's a bit hidden, so nobody
  84. didn't find it so far, and then you get a
    very nice thing, which is this live data.
  85. And it is not encrypted and it's a summary
    of your current data. So, two things about
  86. this - first of all, you can sniff it,
    it's plain text, everyone could sniff it.
  87. And everyone having authentication
    credentials can enable it. And, well,
  88. Fitbit fixed this on their last Firmware
    update in the sense of that you can
  89. disable the live mode if you wish to, but
    you can still use it on any tracker where
  90. you didn't disable it manually and it's
    present in the most recent Ionic smartwatch.
  91. Now Daniel is going to tell you more about
    the firmware and hardware access.
  92. D: Alright. Thank you.
  93. For or some of the stuff which we already
    told you, and also the dynamic debugging, we
  94. want to have some access to the
    actual hardware, so the tracker itself.
  95. But first of all let's look at some
    schematic on how the PCB is structured. So
  96. we have the main system on a chip, which
    is from STM in our case. Here it's based
  97. on an Cortex M3, and we also have of course
    BLE chip, which is used for communication
  98. with the smartphone app. And we also have
    an accelerometer which detects your steps.
  99. And everything is connected via bus. And
    most interestingly, we also know for some
  100. of the software which runs in the
    firmware, basically which library they
  101. used. So for example for encryption, we
    know that they use LibTomCrypt, and for
  102. BLE we at least know that the LibBLEShield
    is very similar to what they use in the
  103. firmware. So this really helped us in
    reverse engineering. So this is what the
  104. PCB looks like if you tear it apart and
    remove it from its casing basically. We
  105. already see that there are lots and lots
    of testing points, and now this time we
  106. figure out what testing points we need to
    connect the debugger. And so we figured
  107. out, or some other guys already figured
    out that you need those four. So,
  108. depending on what protocol you want to use
    for your debugger you need various amounts
  109. of testing pins, and herefore in our case
    we use SWD, so we just need four pins.
  110. Namely testing point 8, 9, 10, and then
    ground pin. And, so you can also see that
  111. we use just the ground pin from the
    battery which we removed previously, and
  112. on the right hand side is just the
    connector switch you can use to connect
  113. it, the Fitbit, to your power supply. And
    so with this we can already dump the
  114. firmware, and we can also modify the
    stored data. And now that we have the
  115. firmware, let's have a closer look into
    it. By the way, this on the right hand
  116. side is our test setup It may look kind of
    crude, but it worked.
  117. And, so yeah, the memory layout is
    basically split up in 3 parts. We have a
  118. flash which contains the firmware code,
    and EPROM which contains the data which
  119. should survive an empty battery, so for
    example your fitness data. And also an
  120. SRAM which is used for, or which provides
    some space for firmware variables. So if
  121. we look into the flash for example in a
    more detail, we see that there are
  122. actually 2 independent firmwares or stuff
    which runs on that. So we have a part
  123. which is called BSL, and a part which is
    called APP. And the reason for that is you
  124. always want to have some fail safe mode
    when you update the firmware. So jiska
  125. will talk about more this... about this in
    more depth, in later slides, but for now
  126. just keep in mind that there are two
    parts. And on the EPROM we have apart
  127. from this fitness data, we also have
    everything we need for encryption, so we
  128. have our serial number. We have an
    encryption key and we have even a switch
  129. which you can use to completely disable
    encryption.
  130. So what we also wanted to do is enabling
    GDB access, so to have dynamic debugging
  131. support. But we discovered this in case
    you set everything up and you connect GDB
  132. to it and then you hit run, your GDB
    connection will just reset after a certain
  133. point when the firmware boots up. And the
    problem is that the firmware actually
  134. disables these GPIO ports during the
    bootup. So it uses this for other stuff,
  135. which is bad for us. And so we decided, so
    what can we do to reenable them. Yeah,
  136. just we modify the firmware. And so in our
    group we already developed this nexmon
  137. framework which we use previously to
    binary patch some wifi firmwares, and now
  138. we just adapted it - [ironically:] just adapted it - for
    the Fitbit firmware. And now we are able
  139. to modify the firmware in any way we want,
    and of course we can just reset the GPIO
  140. pins after the bootup to be capable of
    debugging. So now we have basically GDB
  141. access, can set breakpoints and memory
    watchpoints. Which really helped us in
  142. reverse engineering.
    So now jiska will tell you more about
  143. wireless firmware flashing.
    j: You might have seen our nice setup with
  144. the open Fitbit, but it's quite hard to
    open a Fitbit. So it's not super hard, but
  145. it's hard to use it again after it's
    opened. So the idea is now to wirelessly
  146. flash your firmware, which needs some more
    reverse engineering in the firmware of
  147. this process, and then we were able to do
    it. The update process is a bit
  148. complicated, so in each activity data that
    you transmit to the server, you include
  149. the firmware version of the tracker. And
    the server then knows, well you have maybe
  150. an outdated firmware and in this case in
    the app there is shown that there is a new
  151. firmware update available. But it's not
    flashed onto the tracker until the user is
  152. actually tapping this update in the app.
    But, this is not really a security feature, so
  153. anyone could trigger a firmware update.
    It's not any user interaction required
  154. normally. As soon as the update is started
    you get a microdump from the tracker,
  155. which contains tracker metadata including
    the serial number and the firmware version
  156. once again, which is attached to a
    firmware request. And the firmware request
  157. is then being replied from the server and
    contains the BSL and APP firmware parts
  158. which Daniel just showed you. The firmware
    starts then with the BSL flashing. The BSL
  159. is first validated, then it's written to
    the flash and then you reboot into this
  160. BSL part. Same thing then for the APP
    part, which is again validated, written to
  161. flash, and then there's a reboot into the
    APP. And in the APP you have the normal
  162. functionality back again.
    This update format ensures that you are
  163. flashing the correct firmware in the
    correct order to the tracker. So each
  164. chunk in the firmware is starting in the
    actual tracker model. So each of them has
  165. this hex code depending on the tracker
    model. Then you have a chunk which is
  166. marked either as BSL, APP, or the reboot
    action. And depending on which of these
  167. actions you have either some zero bytes or
    the actual content. And you have also a
  168. size limit of something like 64 kilobytes,
    depending on the tracker. So you just need
  169. to attach these things together. So if you
    have an APP firmware update it contains 3
  170. chunks, then 1 empty chunk, and 1 reboot
    chunk. And all these chunks are attached
  171. to each other and then there's another
    header. The header's having the encryption
  172. options and if it's encrypted a nonce and
    the end has another CRC or if it's
  173. encrypted you have a CMAC tag. Now you
    would say - well, you discovered how the
  174. firmware update works and that's nice, but
    if you do it like this you will still get
  175. some errors.
    So, the address range is of course
  176. checked, you could pass this address range
    check if you would flash one more round
  177. and then disable this address range check.
    But okay, then you have a bitflip and CRC
  178. somewhere in the middle of the firmware,
    where you need to flip a bit, calculate
  179. another CRC, include it into the firmware,
    because otherwise the firmware that you
  180. flash will not boot and show you firmware
    version 0.0 in all activity dumps which is
  181. not that nice, so you cannot simply
    replace a string in the firmware for
  182. example without this being to happen.
    And now Daniel is going to tell you how
  183. the encryption on top of all this works.
    D: The problem is, so we now know how we
  184. do firmware encryption in plaintext mode,
    but most of the new trackers basically
  185. have encryption enabeled by default. So
    what we now need to do is to just build an
  186. encrypted firmware update. What do we need
    for that? Older models of the trackers use
  187. XTEA for encryption whereas newer models
    use AES. For this you need basically three

  188. things: 2 byte nonce which is contained in
    each and every dump you get, a 128 bit encryption
  189. key which you can get with the
    aforementioned memory readout attack and
  190. also an 8 byte MAC which you can just
    calculate. For this they use LibTomCrypt
  191. which is a C-library, which we told you
    before, but you can also use the
  192. spongycastle library which is in Java.
    This also contains every function you
  193. need. Now we know everything we need. We
    know how the communication works, we know
  194. how the firmware update is structured and
    we know how to encrypt it properly. Let's
  195. put it all together.
    Here are 6 steps which you need to do when
  196. you want to build your own modified Fitbit
    flags firmware. First you get your
  197. symmetric key, then you get a plaintext
    dump of your firmware binary. You transfer
  198. everything to a notebook or any PC
    basically which you can then use to run
  199. our nexmon framework and then you modify
    the firmware in any way we want. For the
  200. first and last two steps we have an Android app.
    You can see the URL and the source code
  201. above. And for the nexmon framework, the
    adapted version, we have also another repo.
  202. The last two steps are: transfer the
  203. firmware back to your smartphone,
    reencrypt it and flash your tracker with
  204. it. Of course we did this before and now
    we can show you a nice demo of what you
  205. can do with it. Of course you want to
    modify your fitness tracker in an
  206. interesting fashion. So for example we
    just modified it so that each and every
  207. step gets multiplied by 100. Here you can
    see: I shake the Fitbit and each shake
  208. creates 100 steps.
    applause
  209. And maybe it is good to say that this does
    not work with the latest firmware update.
  210. It says firmware update is necessary. But
    this is because we told them that this is
  211. wrong. So this October update which Jiska
    mentioned came out after our research.

  212. J: These modifications, you can apply them
    on a Fitbit 1, Flex or Charge HR. For the
  213. 1 and Flex the firmware update is not that
    far ago so you have high chances to modify
  214. your tracker if you now buy one that is in
    original packing or if you just didn't
  215. update yours because it was lying around.
    For the live mode it is even nicer because
  216. live mode is there on all trackers so if
    you are happy with the data you get in
  217. live mode you can just disable the
    internet connection of your tracker and
  218. extract all your data with this.
    To sum up our task: Go out and flash your
  219. neighbor's device, keep control of your
    own data, and run any code on your Fitbit.
  220. applause
  221. subtitles created by c3subtitles.de
    in the year 2017. Join, and help us!