 So, I guess we start. Thanks everybody for showing up so early. I guess we are the first talk today on the IoT Village. I still need to get this somewhere near my mouth. Okay, so I'm Daniel, this is Hiska and Caroline and we will present our work on Fitbit fitness trackers. Our talk is called Fitness Firmware Hacking, the Current State of the Heart. And this basically summarizes our research from the last few years. And all the work we are presenting was done in the secure mobile networking lab. So, a brief motivation. A few years ago, I guess like 2017, there was this article in the telegraph which talks about privacy in the Fitbit fitness trackers. But that's not so important. What's more important here is this comment from this guy who says basically, please modify my Fitbit so that I run 10K every day. And we thought why not help this poor soul achieving his goals. And also, if you look like insurance companies, you will get like up to here, Mill mentioned like 1500 bucks like bonuses if you can, if you like upload your fitness data to the insurance companies to show them that you are healthy and stuff like this. So, let's start with the version comparison. So today, we are going to show you several issues and hacks and modifications that are applying to very different versions of the Fitbit. So, we started with the Flex as a simple tracker and also the Child Change R. But Caroline did a lot of work on the Fitbit Ionic. So, there will be very different things on top of this because the Fitbit Ionic has different interfaces which she will tell you. Apart from this, all of them are ARM based. So, the architecture is definitely similar for the Flex and Child Change R and somewhat similar for the Ionic. Yeah, the Fitbit Ionic is the first device within Fitbit's product portfolio to be marketed as an actual smartwatch. And this is because it introduces a number of new functionalities and interfaces. So, for instance, it does not only have GPS or Bluetooth, it also has a Wi-Fi interface and NFC and it has something that is called Fitbit Pay which essentially allows you to contactlessly pay with your watch and you can develop your own custom applications in JavaScript using, for instance, an online IDE called Fitbit Studio. And, of course, it synchronizes data over Bluetooth energy using some form of application, for example, on a smartphone or computer. And, of course, it has a number of different sensors for capturing the user's fitness data. And you can store music files, download radio station playlists, for example, from Deezer or Pandora, and connect your Bluetooth headphones. And the Hungry Cat marks the parts of the Fitbit Ionic that we thought were the most interesting in terms of security research. So, I'm now going to introduce the communication between the Fitbit and the server and this part is very important for you to remember to understand the remaining part of the talk. So, you have a Fitbit fitness tracker and this is connected over Bluetooth LE to the smartphone app and this connection is not that secure. So, it's not that important that it's not so secure because the app is only forwarding this traffic over HTTPS to the server and the traffic is, and to add encrypted with a device-specific symmetric key. So, each Fitbit will have its own key, 128-bit key during fabrication of it and it will be used for encryption. And this encryption only has been on recent records only which means, well, recent, I mean, we started some years ago so any model introduced after 2015 has encryption enabled by default so you cannot disable it but on the orders you could and then also there was a memory attack that was not patched in all trackers. It was only patched in October 2017 on all trackers so there were some possibilities in all the trackers to analyze this communication in plain text. So, what is happening? If you are running, so if you're Susie Fit here in the example you would run and then you have steps that are recorded on the tracker locally and this locally stored data could be something like a week of activity data but usually if you're connected to the smartphone app this data will be transferred to the server just forwarded and then it will be added to the activity database and this activity database has this data then in plain text but you need to actually log in with your smartphone to see this data in JSON so you would get summaries like all the steps of the last week or something in JSON and the mega dumps itself so the binary format from the tracker will also be answered with some settings from the server so this is a different communication here what you see in JSON is a different thing than what you will see in the micro dump, mega dump and now there is a very interesting concept because let's say I have my current step count or my heart rate and I would like to see it in the smartphone app that would be very inefficient to send it to the server each time let the server decrypt send it back in JSON and so on so there is a live mode and the idea here is that the user is logging into the server, does a local pairing with the tracker and then there is a remote association so each time I would log in again I would see the data from this tracker and the smartphone app actually in this step also gets authentication credentials these credentials are only obtained once so that you can later use them offline so that you don't need the server for getting more data and in this authenticated live mode you would get plain text data so that is only the thing that you see as a summary on the display so it's only the total step count of the day, the current heart rate and so on and there was also the possibility for a memory readout and since you can reuse this forever even if you associate the tracker another time this is kind of a critical thing here but we can also understand why did it this way because it's for the offline usage so it's kind of by design that you can reuse it forever so Caroline is now going to tell you about the additions on the Ionix might watch so as I've said the Fitbit Ionic introduces new functionality and has new interfaces that have not been there in previous trackers and for this reason the communication paradigm has also been a bit modified what remains largely the same is pretty much things like so-called server dumps this is something that Diska already told you about it's essentially a generalization of micro and mega dumps and they are sent from the Fitbit service over the Fitbit smart one application to the Fitbit smart watch and also the entire communication on top of Bluetooth energy is very similar but there are also some new concepts for example something that we called app dumps that I'm going to talk to you about later on in more detail and the Fitbit Ionix Wi-Fi interface is used during the installation of a custom application mainly for web socket traffic also for downloading firmware during a firmware update and that's pretty much it everything else is still relayed over the smart phone application and the NFC interface is only used for the transmission of payment traffic to and from a payment terminal and of course as I've said you can connect your Bluetooth headphones using Bluetooth okay so one important step during our research was accessing the hardware you can start with disassembling the app of course or taking dumps from I don't know HTTPS but to get a whole picture we thought we also want to get access to the hardware itself so to quickly show you our threat model so we still have Susie Fit who stores her activity locally on her tracker and of course this tracker has a local symmetric device key but now what happens if Susie is not so active anymore and likes to modify her own data or get her own data so our goals are to access the local data storage and to get the encryption keys so first stuff you do of course is to search for ebay and buy all the trackers you get your hands on and so in our case the Fitbit Flex was pretty cheap already so broken ones you could get up into batches of 20 for $1 each and so here's a quick look at hardware and software of the Fitbit Flex so you have your main system on a chip you have which in this case is a chip from STM it runs a Cortex M3 ARM and the firmware consists of a few libraries which we identified they used so for encryption for example they used LibTomCrip and for BLE they used a library which is very similar to the BLE shield and of course apart from the main SOC you also have your Bluetooth chip which is from Nordic Semiconductors and an accelerometer and here in the Fitbit Flex example everything is connected via an UR bus so if you pry open the hardware so this is pretty easy on the Fitbit Flex you just use a heating gun, heat it up and then you can basically pull it apart and you will get to the PCB so here we already removed the battery and the vibration sensor or vibration actuator and so you already see that there are many testing points and the most important ones are these so a TP8 and 9 are used for SWD debugging and you can use just the ground from the battery to connect it to your debugger and apart from this there is also TP10 which you can use for resetting and yeah that's it you have everything you need to hook it up to a debugger and so here on the right hand side this is how it looked in our case we just used the ST-Link debugger from STM and in the breadboard basically and with this we were already able to read out all the memory so it consists of three big parts a flash, an EEPROM and an SRAM the flash contains of course all the firmware code the EEPROM stores all the data you want to get your hands on and the SRAM of course for firmware variables we have a closer look at the flash you will see that it consists of two big parts an app part and an BSL part Jiska will tell you more about these later but the important thing is that they can run independently from each other and the EEPROM as I said contains all your fitness data but also like the serial number of the Fitbit an encryption key and an encryption switch so with this switch it was possible to disable encryption completely but nowadays the backend will not accept connections which are not encrypted anymore so this does not work anymore so one important step also was to re-enable GDB access what we discovered is basically that you only were able to connect to the Fitbit to the reset before this and after this if you hit continue on your GDB the connection to the debugger will be lost so at some point in time it needs to apparently it remapsed the GPIO ports to something else but not like to something which we need for debugging so we thought why not reset them to something which we actually need and what we used for this is the Nexmo and patching framework so we already developed this for a previous project and with this framework we are able to binary patch the stuff basically and we adapted it for our needs of course our goal was to modify the firmware and enable the dynamic debugging so this is what the core graph looks like for after initialization so at the beginning GDB access still works and somewhere after the initialization it doesn't work anymore so I have no idea where exactly these GPIO ports are reassigned but I actually don't need to know so what we just did instead is to add an additional Bluetooth command to remap the GPIO ports to re-enable GDB access and for this we did this with a special Bluetooth command because we did not know which other use case they had for this GPIO and we just wanted to keep the side effects as small as possible and with this of course then we were able to have breakpoints and memory watch points and all the good stuff so naturally we also had to look at the Fitbit Ionix hardware and we did this by using two broken Fitbit Ionix smartwatches and the goal was for us to understand the hardware that is used and also to find possibilities for debugging and what you see on the picture below is the Fitbit Ionix main PCB being powered by its battery pack and it has 39 copper wires sorted to its back and is connected to a logic analyzer and since the Fitbit Ionix main PCB is rather small this entire setup always reminds me of the flying spaghetti monster what you see on this picture are all the hardware markings that we deciphered from the chips on the Fitbit Ionix main PCB using a microscope and what you see from this is that the Fitbit Ionix uses a Cypress Bluetooth chip a Broadcom Wi-Fi and an NXP NFC chip and also the CPU and the flash memory are manufactured by Toshiba and the CPU is custom built for wearables and smartwatches and it contains an ARM Cortex-M4 and it does not have JTAG interface but instead uses SWD which is short for a serial wired debug and on the right hand side you see a comparison of the Fitbit Ionix main PCB to the main PCB of the Fitbit Flex and what is noticeable is that the Fitbit Ionix has a lot more stuff going on on the PCB and it's a lot more densely packed and more complex so there's definitely an involvement there this is the main PCB from the back with all the different testing points there are 95 in some and we tested 39 of them using the logic analyzer under different conditions and we wanted to identify which testing points correlate to the SWD interface unfortunately, Murphy's Law this did not yield the desired result instead we found that testing points 25 and 28 are responsible for SWD clock and input output respectively after we desoldered the main CPU so if you want to follow up on this these are the testing points to look for and this is what the flash memory and the main CPU look like desoldered so the first thing to note about the flash memory is that we were not able to find any information on the public internet about the manufacturer parts number on this chip we found one that was very similar that had just one letter exchanged essentially but it was bigger and this is why we think that it might be possible that this chip is even custom built for the Fitbit Ionix so the thing is that it is not that practical to open up a Fitbit to then change your step count or whatsoever so what we wanted to do is also to understand the wireless firmware flashing process to flash our own firmware that modifies something so the firmware update process usually works as follows you just have this same mega-dump synchronization with the server and the server realizes hey I have a new firmware and then this firmware is actually shown to the user and the user needs to confirm to do a firmware update and then again the tracker is sending a micro-dump and there is the firmware request to the server and the answer to this contains two parts which Daniel was already talking about a BSL and an app so app here is not smartphone application but the main application running on the Fitbit tracker and first the BSL is flash validated and so on and then there is a reboot to BSL and then the same happens to the app so the idea is that you cannot pre-create your tracker which means so if I cannot reboot to BSL then my BSL was wrong and then I can still boot the app so far so good another thing that you need to understand is that I still have a memory read-out attack but do encryption is how the encryption itself works so we did a bit of reverse engineering and found that the tracker is using lip-tom-crypt and with this it was also easier to find out how the nonce is used how the encryption key is used and that they have a Mac so the Mac also means that you cannot easily get a bit here and there to change the behavior because then in the end it will no longer match with the authentication Mac so you really need to understand how the format works and how the encryption works so if you want to flash a modified firmware first of all you need to get the encryption key or you have a tracker that is still in plain text you can achieve that actually if you buy one of the older trackers you can connect it to the internet so beginning of this year I was still buying trackers that could be modified but only the very old models and then you need to find someone buying one of those models that has never been unpacked so if you have the key you can then also read out the firmware if it's not already a firmware that we already have then you can copy the firmware modify it with Nexmon and copy it back to the smartphone app actually already has a few firmware images built in so if you just want to have one of the images that we provide you don't need to do this part but probably you are interested in binary patching and want to have your own patches and then you need again to format and encrypt the firmware and flash it back as I explained and yeah so the pre-compiled firmware that we have has a couple of funny features so the first feature we actually did when we had our first demo so when we gave our first talk and it is just returning the step counts times 100 so you need to do less points and it will still look somewhat realistic to the server so you could do some more advanced stuff here like replaying activity records or something but we just do the steps times 100 and another funny thing that happens so if you then are resetting the tracker to this patch and already have a high step count then it is like taking the square of this or something so it is getting super high numbers and this is really funny because then if you have a Fitbit account in your inbox you will have all the notifications of like you got the New Zealand batch of crossing all of New Zealand in one day and so on I don't know so that's really funny what happens if you do this and yeah you definitely can do this maybe you shouldn't do too much of this because if you have a health insurance and want to tell the health insurance I am doing sports and then they are like yes but you did like two billion steps then it might be strange so be careful with this and then beginning of this year I also ported this code to the Fitbit Charge HR which is also cool because the Fitbit Charge HR has a display and display means that you can take the smartphone app with you so you can just show like oh I did a lot of steps today I was doing sports before coming to your party and then you don't need to move a lot on the party because otherwise they will think like how did you do five thousand steps on the party okay so the accelerometer is one thing that we thought is very interesting to access because there is like or at least has been no good tools with trackers that are waterproof at accelerometer readings and there is almost no strings in the firmware so it's very hard to reverse engineer but one thing that is there is factory test mode with some basic console and luckily so one of the very few things that has a string is a command to test the accelerometer and with this we found out how the accelerometer is configured and the most important part is configured to make measurements with a rate of 100 hertz so 100 measurements per seconds I think this type of accelerometer can also be configured differently so to something like two kilohertz which would mean that you could also record or recognize some speed derivatives but the 100 hertz is totally sufficient for recognizing some gestures and movements actually already something like that would be okay so the question is could we get the readings of the accelerometer somehow out of the tracker with at least a rate of 25 hertz and the next problem is a bit that we are restricted in how to patch this because we do binary patching which means writing code from scratch aside it's easier to reuse existing functions so what we did is we made a switch into the live mode so we are using the live mode and then we are copying the XYZ values to the live mode and the rate of this is the blue to valley packet rate and so you can put out the readings with something like 66 hertz so it's like not as much as the original readings but it's still sufficient if you want to develop something that the use cases are various so for example you could now develop your own algorithms that do something with accelerometers so recognize I don't know some gestures on top of step counts and this you could do with Python or whatever you like on your smartphone and Java or whatever and then once you have all the logic of how to recognize those movements you can then see code with next month because putting out the readings over Bluetooth is draining the battery a lot so it's nothing to do forever but at least for development it's very interesting so the versions that you can modify is actually if you buy Fitbit one flex or charge HR that has never ever been updated so a fresh one from the internet something like it was never updated since October 2017 and the charge HR would also allow you to access the heart rate sensor so there's also some help commands with this but we didn't release a patch through this so far but if someone is very interested we can look into this of course so much about the trackers and now we are going to tell you about some of the insights that we gained during testing so as I already mentioned the most interesting parts of the Fitbit Ionic from our point of view are Fitbit pay the custom application installation capability as well as the way that the Ionic synchronizes data synchronization is very interesting because we found that it heavily relies on the old Fitbit ecosystem and reuses old functionality and we wanted to see whether all the old vulnerabilities are still present there one thing to know about custom applications is that the process of installing heavily relies on the Wi-Fi interface and for this Fitbit consistently uses TLS and sometimes for example during the download of firmware they even use mutually authenticated TLS using communication or modify communication so I'll skip applications and focus on Fitbit pay as well as synchronization in the next couple of slides so one thing that I've talked quite a bit about already is Bluetooth energy and as the name suggests it is closely related to Bluetooth yet a bit different because it has been designed for energy constraint devices it operates on the channels of which 37 are used for data transmission the generic attribute profile is another layer within the Bluetooth energy protocol stack and it groups related information into services and characteristics and the smallest bit of information on this layer is called an attribute hence the name generic attribute profile so the Fitbit Ionic uses Bluetooth energy 4.2 setting otherwise on the official website which is weird it says 4.0 on the website and Bluetooth energy is not known for being the most secure standard by design there is one pairing method called just works which essentially is the most unsecure pairing method that you could use because it does not use authentication and depending on the Bluetooth energy version you can also launch active and this is precisely what the Fitbit Ionic uses it enforces the use of just works pairing you cannot use anything else with your smart watch and we assume that this is due to usability issues because it does not require user interaction also the Fitbit Ionic exposes five different services on the generic attribute profile layer and two of those services are proprietary and these are used by Fitbit Ionic and the application layer protocol is what I'd like to dive a bit into in the next couple of slides some things are legacy and have already been present in previous trackers and some things are new and specific to the Fitbit Ionic so one thing Yiska already mentioned is the so-called live data which is the real-time fitness information of a user and this is still included and present on the Fitbit Ionic another type of data that is present on this application layer protocol is so-called command messages they either instructor receiving side to take a certain action or signal state and there have been modifications to previous ones or older ones from older trackers for the Fitbit Ionic and there are also a couple of new ones that have been introduced in the Fitbit application one thing that is new to the Fitbit Ionic are something that we called app dumps because they are exchanged between the Fitbit application and the Fitbit Ionic and they are encrypted dumps encrypted blobs of data they are encrypted using AES in EAX mode using a symmetric key of course and this key is derived using a proprietary session key of the Fitbit we reverse engineered this protocol and unfortunately for us we did not find a practical exploit but only a theoretical attack on this protocol because it has two independent stages and the semantics of the app dumps are defined in a construct that is called the Fitbit mobile data protocols which essentially is a set of XML files that define which bit and byte within a protocol about app dumps is that it is the first time that the application and the Fitbit tracker or smartwatch has the capability of exchanging encrypted blobs of data previously this was only present or possible between the Fitbit tracker and the Fitbit servers and if you are interested how all of this works I have a little Python script that demonstrates a little proof of concept to show you how app dumps work and how the session key I mentioned this server dumps are still present on the Fitbit Ionic there exchange between the Fitbit servers and the smartwatch and they are also encrypted blobs of data using a symmetric key and if you want to get to that data you either have to hack the Fitbit servers or your Fitbit Ionic because that's where the keys are it is completely transparent to the Fitbit mobile application and for the Fitbit Ionic and when I heard that you could now pay with your smartwatch I had really high hopes that it would be really insecure so I could find a lot of things you can use Fitbit Pay if you have a supported credit or debit card by one of the banks listed on Fitbit's website for instance the Bank of America is supported or the German Bundesbank Baden-Württemberg and all the payment traffic is transmitted on the NFC standard or EMV specifications and EMV is short for Europe International MasterCard and Visa and those are just three organizations that work together to create a common specification for credit card payments the credit card information is managed using the Fitbit mobile application and for this purpose Fitbit registered a new web API that is located under the domain Pables.co and to do this we used an app that is called NSCGate which has been developed within the Seymour Research Group the Secure Mobile Networking Lab and if you're interested in sniffing your own payment traffic using this very cost effective setup you can go to the link below of this slide which is NSC.wgf and what NSCGate does essentially is it creates a Wi-Fi wormhole so the first app on the first smartphone captures the NSC traffic on the NSCGate server that is also able to lock the traffic and from there the traffic will be relayed to the other NSCGate app where the data is sent via NSC to its destination which in this case is the payment terminal and vice versa okay so after analyzing and experimenting with this we found unfortunately for us that it is rather secure in terms of what is recommended in the EMV standard so for instance something that is called tokenization is used during payment which means that your credit card number is never transmitted in plaintext instead it is replaced with a so-called token which essentially is a pseudonym for your credit card number also a so-called authorization request cryptogram is used which is a Mac that is computed among other things over the transaction details like the card's master key and the transaction counter and what this does is that the transaction cannot be modified or replayed and last but not least a four digit pin is used as soon as you decide to set up Fitbit Pay which is supposed to lessen the probability of someone else paying with your watch and it is also used during a process that is called consumer device cardholder verification which proves your identity when paying with your Fitbit Ionic is pretty much the same than paying with your contactless plastic credit card yeah okay and next I would like to dive a bit into all the vulnerabilities that we found on the Bluetooth interface which is something that we dedicated a bit more time to and for this purpose I grouped all the vulnerabilities who identified in two categories on the right hand side you see all the vulnerabilities that are new to the Fitbit Ionic and have not been present in previous trackers and on the right hand side you see the vulnerabilities that are due to legacy implementations and have been known to be present in previous trackers and what is pretty obvious is that the right hand side is much larger there's much more vulnerabilities and this is because Fitbit relies on its old ecosystem and has a need for backwards old vulnerabilities to still be present instead of explaining each and every one of those vulnerabilities I'd just like to point out the main points of criticism that we have here and that are or that essentially cause all of these vulnerabilities so one thing that I've already talked to you about of course is the weak Bluetooth or energy pairing that just works pairing method and also we found that Bluetooth or energy security is inconsistently enforced this time between your Fitbit Ionic and the smart one application Bluetooth or energy or pairing does not instantly kick in instead it takes some time until pairing happens and during this time all of your data will be transmitted in plain text which of course is not that great so our recommendation would be to use secure connections whenever possible which is present in Bluetooth 4.2 and use a pairing method that uses authentication also Yiska already said authentication credentials for live data and this problem is still present on the Fitbit Ionic so if an attacker through whichever means acquires those authentication credentials they will forever be able to request live data from your smartwatch and of course this is also something that you do definitely not want so the reuse of those authentication credentials should be prevented for example by associating them with a validity period or if that's not possible maybe just plainly without that often. Another problem that persists is that live data is not protected on the application layer and this is a problem if you use a weak Bluetooth 4.2 pairing method as the Fitbit Ionic does or if at the beginning of each connection the traffic is not instantly protected so our recommendation at this point would be to encrypt live data with a similar mechanism that app thumbs are protected with real-time data would not be entirely real-time anymore but security has never been convenient so and last but not least I also found some testing commands to be present in production for example I found a command that allows you which is one command to request a very large test dump it's just meaningless test data but it's rather large and I was able to keep the Fitbit Ionic sending for 45 minutes straight longer and what it does is that it drains the Fitbit Ionic's battery quite quickly and for whatever reason the UI becomes very sluggish and unresponsive so you can't really use your smartwatch anymore and that's just pretty much unnecessary so our recommendation would be to employ a process that ensures that all your testing code is not rolled out to production which is probably something that is standard to our talk we have three major points which we want to point out so in general we can say that Fitbit products improved a lot during the years which we observed them in general they have the problem of compatibility for older trackers so the app still needs to have this legacy protocol which needs to talk via Bluetooth and in general it seems that Fitbit just likes to implement encryption in weird ways so that's it from our side thanks for your time and I guess we have now some time for Q&A questions so the question was if we already looked into the app right so do you want to talk about this so we looked into the app so Caroline did it and me too for understanding for example how the firmware slash and so on and we patched the APK and made some debug prints and so on to get an idea of what is going on so the question was with the secure connections and the pairing how it works and why it kicks in later so I do not know why but I would expect that you pair or use a secure encrypted connection smartwatch and the application that this just doesn't happen they exchange data for a couple of seconds and then randomly pairing starts I don't know why but I've seen this quite a lot when testing so the question was if we also looked into other smartwatches so actually another group at our university initially did a study on fitness trackers in general 17 trackers, different kinds and what they found out is that most IoT fitness trackers do not even encrypt the data so we actually picked Fitbit because we thought it's like a very interesting ecosystem they have encryption and so on so it's like we are hacking the strongest implementation but yeah yeah so the question is there is some Fitbit with GPS I think it's the Fitbit series or something but that one has been produced after 2015 so it's encrypted and then it's harder to do it so that's why we just went then straight to the Ionic to see what changed I assume that some stuff would be similar so if you would open the PCB and so on then you could maybe extract the firmware again with the one encryption key that is on this very same tracker and that's a lot of effort for just hacking one device okay then thank you for listening we will be around here for a bit more if you have any questions also on how we patched the firmware for example that might be interesting for some of you yeah thank you