What did we discover about the world’s cyber workforce capabilities? Dive into the data with us to find out. Read More
Home > Blog > Research: Can you build spyware for a Fitbit?
Research: Can you build spyware for a Fitbit?
Kev Breen, Director of Cyber Threat Research at Immersive Labs, recently conducted research into the Fitbit app store. This is what he found.
Having developed a number of malware analysis and network security labs, as well as having a healthy interest in spyware published to the Google and iPhone app stores, I was curious to see if I could write a malicious Fitbit app that would bypass the protections in app stores. I also wanted to see if this could be used to attack an enterprise.
I discovered a way of delivering a malicious Fitbit application from fitbit.com.
I wrote and uploaded a piece of spyware/stalkerware capable of stealing everything from location and personal body data to connecting to company networks for a range of malicious actions.
It bypassed protections because it was delivered from fitbit.com, meaning it installed inside the Fitbit app as if it were legitimate.
I reported this to Fitbit, who have moved to mitigate the issues.
If you’re more of a listener than a reader, tune in to this special episode of Cyber Humanity to get the full break down of Kev’s findings:
What could the malicious app do?
While not as pervasive as some spyware, I was able to create a watch face that would send the following example data to a remote server that was under my control.
Essentially, it could send device type, location, and user information including gender, age, height, heart rate and weight. It could also access calendar information. While this doesn’t include PII profile data, the calendar invites could expose additional information such as names and locations.
So how much information could I actually get, and where was it coming from? At this point, I was not querying the Fitbit API server directly – I was only taking information that existed on the device.
The Fitbit application API exposes access to individual device sensors, like GPS, heart rate, accelerometer and body presence. It also exposes a limited personal API from which I can read age, height, weight, sex, and average heart rate. This API can connect to the internet and read calendar events if synced.
With internet access and the ability to run in the background, I could send all this data to a server of my choosing. Looking at the Fitbit community, there were discussions between developers around storing user data on the app developers’ servers. This would not be owned, operated or controlled by Fitbit.
I did not see any obvious enforcement of privacy policies for individual applications and watch faces installed onto my Fitbit, such as opt in or opt out, without explicitly blocking access to the internet. I understand that users have the option to install or not and to accept permissions or not, but I question whether they are fully informed about the data being collected.
The Fitbit SDK also exposes a web API that can be used from inside my application. This requires the user to open my app settings page inside the Fitbit application and approve the app to talk to the API using OAuth. While this would be more complex to build into the application, and some users may not complete this step, any that did would find significant amounts of data available, as outlined here. This would include name, date of birth, city, county, history, of all your activity, a list of your friends, when you go to sleep, when you wake, etc. This is exactly the kind of data you would expect from a smart watch/exercise tracker – and as with most things, it is open to abuse.
As the fetch API allows the use of HTTP to internal IP ranges, I also managed to turn the malicious watch face into a primitive network scanner that could scan and access internal network sites and services. This was a simple case of setting up a server to scan IP addresses and writing a simple routine that would allow the watch face to connect to and execute this code. With this functionality, my watch face could become a threat to the enterprise. It could be used to do everything from identifying and accessing routers, firewalls and other devices, to brute-forcing passwords and reading the company intranet – all from inside the app on the phone.
For the purposes of testing and as a protective measure, this watch face had all communication disabled by default and required users to manually enter a valid server address in the settings page, which is empty by default.
A legitimate-looking fitbit.com URL for delivery
The Fitbit gallery is a section of the company website designed to showcase Fitbit apps and watch faces.
For this reason, I was surprised how easy it was to publish my malicious watch face to a gallery.fitbit.com URL. Using a dashboard used by development teams to preview apps, I submitted my spyware and soon had my own URL at https://gallery.fitbit.com/details/<redacted>. My spyware was now live on fitbit.com. It is important to note that while Fitbit doesn’t count this as ‘available for public download’, the link was still accessible in the public domain and my ‘malware’ was still downloadable.
Hosting the app on the official Fitbit URL added significant legitimacy and would increase conversion rates for malicious email or malvertising campaigns, as well as more targeted distribution techniques such as sharing the link directly in forums or via Whatsapp.
It also meant that when the link was clicked on any mobile device, it opened inside the Fitbit app with all thumbnails perfectly rendered as if it were a legitimate app. From there, it was just a quick click to download and install, which I did with both Android and iPhone.
It’s also interesting to note that when installing, permissions are pre-selected and Fitbit prompts the user to accept all. However, the calendar permission was not automatically selected on the iPhone.
By default, the app I created had no callback domain configured. It had to be manually set in the app’s setting pages to prevent it from being accidentally installed and sending data.
Unlike many vendors being presented with a potential issue, Fitbit responded both politely and promptly when I pointed out what I had managed to do. As any security researcher knows, this is better than many organizations.
With regard to uploading applications to the gallery, I was advised that apps submitted to the Fitbit Gallery for public download undergo manual review and that obvious spyware or applications masquerading as something else are likely to be caught and blocked from being published. This is standard stuff, but to my mind did not address the issue of malicious apps being available from the Fitbit domain prior to being officially submitted. This, in my opinion, presented a social engineering vector. At the time of writing, the malicious watch face was still publicly accessible.
After further discussion, Fitbit agreed to make a number of improvements to make their ecosystem safer. First, they have agreed to add a warning message for users within the UI when installing an app from a private link. Second, on the installed apps/clocks list on the mobile device, they will make it easier to identify any apps which are not publicly listed. They have said they will make these changes by today (9 October 2020). Finally, Fitbit has committed to adjusting default permission settings during the authorization flow to being opted out by default. This change will take a little longer to roll out, but it will be immensely helpful in protecting the user.
I was also advised that social engineering attacks are not currently rewardable in the bug bounty program – not that I was looking.
The app itself was easy to write. However, I will not be releasing any of the code and have deleted the application before this post was published to ensure it will not be used in the wild.
At the time of writing, there are no checks within the Fitbit ecosystem at point of app installation. Currently, it is the responsibility of the Fitbit devs to screen and approve the public listing of applications. However, as demonstrated, it is simple to get an app up on a fitbit.com URL – even if this doesn’t count as ‘published’, they are still shareable and can be downloaded.
People should be cautious when installing apps from links either in emails, ads, social media posts or other untrusted places; you should search for it by name in the Fitbit gallery. Also, be wary of how much permission the app is requesting from you. Remember, you are in control. Just because they are preselected doesn’t mean you can’t untick the ones you’re not comfortable with.
Finally, if in doubt, don’t install it!
Kev Breen, Director of Cyber Threat Research, Immersive Labs