One massive branch of Internet-of-Things’ market is still and will be for a long time the field of eHealth and activity tracking. As one of the well-know great players in this segment Withings (now part of Nokia) released a combination of tracker and bodyweight scale with some innovative features like e.g. pulse wave velocity measurement. The data collected by tracker, scale and potentially a whole sortiment of other devices is merged and processed via Health Mate application and stored on servers around the world.
As exciting and useful devices and features like that seem, they can always bear serious implications for user privacy and transparency – especially when implemented in a vulnerable system.
AV-TEST takes this for a reason to put the security of the Withings eHealth combination to the test and find out whether or not it lives up to our expectations.
We analysed the “Health Mate” Android application (com.withings.wiscale2; version 3.1.0) in search for obvious security flaws and possible vulnerabilities. Reverse engineering the application revealed at first that a solid code obfuscation is used which effectively hindered us from easily analysing every bit of the application code.
Our automatic static code analysis delivered four supposed critical security flaws within the app code (the following image shows an excerpt from the analysis result log). Especially the three problems regarding SSL security can be disastrous for the overall communication security of the app.
The first reported problem was the use of the “ALLOW_ALL_HOSTNAME_VERIFIER” which basically means that the validation of the CN (Common Name) of a SSL certificate is not properly checked. The result could be the possibility for certain Man-in-the-Middle attacks but as the code is heavily obfuscated and we did not review every little bit of code, it may be possible that a CN check or an effective alternative is implemented elsewhere. To come to a final evaluation, we had to perform practical tests to determine whether or not the application is possibly vulnerable to MitM attacks. The results are presented in the next section.
The other two problems are found URL’s which are not under SSL but none of these are critical for the app functionality.
The last reported problem regarded also the SSL certificate verification checking and could also result in possible MitM attacks on app connections. This point could also not completely be checked with a code review and therefore had to be investigated with practical testing.
Furthermore we checked the storage habits of the app regarding unsecured and/or unencrypted user information storage locally. Although we found quite a lot of locally stored unencrypted data, none of it was stored outside the secured app folder. The use on a rooted phone might imply some security problems (as the use of a rooted phone in general does), but except for that there are no real concerns for this point.
The application communicates quite vividly with a whole of different domains. The greatest part of the communication is thereby secured by TLS 1.2 and therefore adequately protected. Only the communication with i2.shared.global.fastly.net was performed over HTTP and without TLS protection. However, the payload of this communication was not transferred in plain text and we cannot rule out the possibility that it might be secured with encryption on data layer.
The tests for potential Man-in-the-Middle attacks revealed no obvious flaws or vulnerabilities – in our test scenarios Man-in-the-Middle attacks were practically not doable. The questioned implementation of the certificate verification mechanics seems to be effective.
As a side note, we like to mention that we observed a great amount of communication to services from Amplitude, Google Analytics and AppsFlyer. Although these connections were all adequately secured, it is quite safe to assume that there is a lot of data regarding user behaviour and information transferred to known third-party analytic services. This does not have to have a negative implication per se but with the highly personal data the Activité and the Body Cardio collected it should at least be mentioned.
The local communication between application and Activité and/or Body Cardio is performed over Bluetooth LE. We logged and analysed the ongoing communication when connecting and synching and checked for possible replay and/or spoofing attacks. Although not all communication seems to be encrypted and secured with time dependent mechanisms, the authentication procedure itself is robust – within the means of our Quick Check there was no way detected to replay or manipulate the authentication procedure. The following image shows an excerpt from logcat showing the authentication and synching procedure of the Activité with the Health Mate application.
As a positive side note we would like to mention the use of Bluetooth LE privacy features introduced with Android API level 21 (Android 5.0). Although not new anymore we seldom see an adequate use of these privacy features in wearables of all types. In this case the periodic randomization of the device advertisement MAC address is used to avoid device and user tracking by MAC address tracking – a gain in user privacy not to be underrated.
- Display recorded data
- Improve services and products (anonymized data)
- Support, if contacted
- Marketing (can be revoked)
A solid product with no real security flaws. Although there a several concerns in terms of privacy and collected user information (these are generally existent for all products of the eHealth/Fitness tracker type of IoT product) we did not find any indicators for real security flaws. The Health Mate application along with the Activité tracker and the Body Cardio scale are therefore awarded with the full 3 out of 3 stars rating.