As you might know we are continuously doing research on medical devices. I presented some of the new results at Power of Community 2014 last week and we thought we would share some of the details with you here. The focus of the previous work was testing medical devices that are used in hospitals like patient monitors, syringe pumps or even MRIs. This time we looked at a device that every user can use at home and which is available to anyone on the market: A smart scale.
The scale implements some basic features as you might have guessed, that is measuring your weight. In this case there are a lot more additional features that you can use, e.g. measuring the air quality, the room temperature, your heart rate and your fat mass. The latter makes testing this device quite hard, because somebody has to step on it and the results were not funny at all and will be kept secret! 😉
The parameters are not only measured, there is also an app for it so you can track how fat you get over time (or lose weight, which we could not confirm during testing). This is where it got interesting for us because the data that is gathered by the scale is beeing pushed to the vendor’s cloud. So this time we were not on the hunt for bugs that might harm a patient physically, we focused more on privacy issues and guess what, we found some.
Configuration is done by using bluetooth and your smartphone. The scale then silently sits in your WiFi to wait for measurements to be made. If there is a measurement, the scale will wake up and push the data into the cloud. The attack surface of the device itself is pretty small. It communicates only when there is a measurement beeing made and given the lack of time we decided to focus on the communication of the scale with the cloud and the smartphone.
The first thing we tried to do was hooking a proxy into our network setup to see what the devices were sending to the cloud and how they communicated with each other. When setting up the scale, it is possible to configure a proxy. We used that approach and it didn’t work. Somehow the proxy would not be set and the app would just crash. We then set up a transparent proxy on the gateway that was able to intercept all the requests for us and went through the same configuration process again. This time, we had some more luck and were able to see requests beeing made from the app to the cloud. When we were able to intercept the process of configuration for the first time, we forgot to deactivate the proxy settings for the scale. When the app crashed we found this on the intercepting proxy:
What you see here are (besides some status information) the SSIDs of the Wifis that the scale could receive when the crash happend. So, sending out SSIDs of neighboring Wifis might not seem to be a critical privacy issue, but we thought that this information must not be known to the vendor. We all know that preventing data is better than protecting it, that is especially true for the next issue.
The following request is issued every time the scale is doing a measurement. Basically it is a big blob of hex encoded data that gets transmitted to the cloud, so it contains information like weight and air quality and we expected some status information in there, too.
When analyzing the dump we found some strings that identified the language that was configured, the MAC address of the scale and then this sequence of hex encoded data:
As we decoded this, it translated to the following: “omfgstfu“.
We recognized this string from somewhere: That was the Wifi passphrase of our lab! So, the scale is sending our Wifi passphrase over the network to the vendor every time it performs a measurement. In our view this is a big privacy issue! There is no need for the vendor to obtain this information. In addition to that, these requests are made by using HTTP. There is no encryption to protect your data while pushing it into the cloud and that data will include your Wifi passphrase.
We also found some serious issues in the services provided for the scale. We were able to extract data from other customers as you can see in the next JSON response from the service.
This is obviously not our data but it contains birth dates, names and key information from other customers.
The vendor did not respond to our requests and reports. We tried to contact them since May 2014 and have not received a single response since, so we decided to publish some of the findings here.
And speaking about underestimated critical findings: we will have a talk on Troopers 15 on IBM’s GPFS with some insight into (not only ;-)) CVE-2014-0834! So stay tuned and have a healthy week,
Florian