Quick Check: Yet another Kids Smart Watch – Xplora X5 Play

This year, as in every September, the next generation of schoolkids began the serious business of life. And even for those who are already in school for a few years, the new school year begins. Classically, this is also the time when many parents not only look with pride at their children’s newfound independence, but also feel increased concern for their offspring. Those who want a little bit of control back and do not want to pack the first cell phone into their child’s satchel, like to reach for the increasingly popular kids smart watches. We take this as an opportunity to subject a currently very popular device from this category to our security analysis – the X5 Play by Xplora. But if past tests in this area have shown one thing, it is that such devices do not only have advantages.

Features

The X5 Play from the Norwegian manufacturer Xplora Technologies basically offers everything that you would expect of such a device: For mobile accessibility, the smart watch can be equipped with a SIM card in nano format or is also available as an eSIM variant. It can also access the Internet via the integrated WLAN module in the home network. If desired, the watch can be located (relatively accurately) via GPS and even record the child’s daily step count via integrated motion sensors. Communication can be carried out classically via a call function or the integrated chat messenger can be used for text, emoji and voice messages. The operating system on the watch is an adapted Android version 7.1.2 (tested version with build number W927_1.0.2208160_dev_user).

Mobile applications

Of course, the X5 Play comes with mobile applications that enable communication with the watch, account management, and all remote functions such as tracking or shutdown. As always, these applications for Android and iOS (com.xplora.xplorao2o; v1.2.73 and v1.3.7 respectively) were first subjected to a static analysis.

The first thing that stands out is the sheer amount of permissions (on Android there are 38) that the application can claim. Many of these can be traced back to the functionality provided by the application, but for some it is difficult to argue with necessity. For example, the application for Android can close the background processes of other applications, change the phone state without notification (i.e. change networks, turn WLAN on and off, etc.) or change the system configuration. Accessing the Google AD ID for retargeting purposes, the accounts in the Account Service, and a list of running processes is also difficult to explain with the provided functionality.

The static analysis was also able to identify 3 tracker modules with entries in the Exodus privacy database and several other third-party non-free libraries. The trackers are two classic Google trackers, namely Crashlytics and Firebase Analytics, as well as the MapBox SDK, which is mainly used for the location function, but naturally offers extensive tracking potential.

However, there are no really critical points to report after the static analysis: In the app manifest of the Android app, as is typically the case, some activities, services and broadcasters can be found that are not sufficiently protected by corresponding permissions, which would theoretically leave open the possibility that data could flow to other applications on the phone. But the threat here is more theoretical. It is also noticeable that the application is configured by default to allow unencrypted HTTP communication (via android:usesCleartextTraffic=true) – but that does not mean that this happens in practice. More about this in the following section.

Online communication

Past tests of similar products often showed glaring vulnerabilities in this critical area, which could quickly threaten the user’s privacy and accounts. As far as the basic communication of the application and the watch via WLAN is concerned, we can give the all-clear insofar as we could not observe a completely encrypted communication, but at least an encrypted communication of critical information. Even the default attacks we always performed, such as man-in-the-middle, were detected and handled correctly by the app. So far so good.

Of course, we wanted to know a bit more about this, and because in past tests of similar solutions we were able to identify the main weak points within the server API, we also had to look at the server side. The first step is to understand how the application communicates with the server in the first place. Since it is not possible to simply read the encrypted communication, there are basically two ways to gain the desired insight. Either one goes the classic (and sometimes very tortuous) way of a good, old-fashioned manual reverse engineering of the source code or one simply changes the application code to such an extent that the encryption is switched off or at least weakened to such an extent that one can break open the communication and read it. If you can then observe how the application performs critical processes, such as authentication, location or sending messages to the clock, you can specifically search for vulnerabilities. And this is where the Xplora solution reveals some serious, but not unsolvable problems.

So first to the authentication. This is done via a combination of account name, in this case the mobile phone number of the guardian, i.e. the parent, and the corresponding password as MD5 hash value. It is generally known that the MD5 algorithm should no longer be used nowadays. However, since the whole thing is transmitted over a securely encrypted connection, we almost want to overlook this here. However, one should keep in mind that in case of a data leak, the passwords are only marginally better protected than if they were available in plain text.

Also transmitted for authentication is a combination of apiKey and apiSecret, two hardcoded secrets. Obviously, these two values are not checked on the server side, because they only have to have the correct length to be accepted, but if they are missing, the authentication fails. If you pass these values (mobile phone number, password hash, apiKey and apiSecret) to the server, you get an Access Token back, which is used to identify and authenticate yourself for further access to data and/or functions. So far so good and so common.

But the problem is the server feedback. If you enter a mobile phone number that is not yet registered on the server, you get the error message “Invalid request”. But if the number is registered and the password is incorrect, you get “Incorrect Password”… So an attacker has not only the possibility to check if there is an account for a known number, he can even search the whole possible search space (in this case all possible mobile numbers) and identify all registered accounts. For each account found in this way, they then of course have the possibility to attack the password.

Now, of course, every reader who is somewhat familiar with the topic will immediately say “But…rate limiting”. Yes, that’s right. But there is no rate limiting here. We have tested only the first 100000 numbers of some German 017x prefixes (about 600000 queries; pure computational effort of a few hours) and have immediately identified over 1500 registered accounts.

If you then just take the top 10 of the “Hall of Shame” of the most common passwords in 2021 and fire them at the identified accounts, the chances are already statistically not bad that you will succeed pretty soon (not that WE would do something like that…). Now you could still say “Yes, but if a secure password is enforced during account creation, guessing is still tremendously difficult!”. Yes, this is also correct. But extremely weak passwords are allowed. The top of the mentioned Top 10 password list, the “password” 123456, is absolutely permissible when creating an account – similar bad or even worse passwords, by the way, are also permissible. And even with a secure password, the attacker still has a whole list of other options for targeting the victim with the help of knowledge about the victim’s valid phone number.

Once the attacker has found the password, he has full access to all functions, such as location and messaging services – which is not only scary for parents. The manufacturer should definitely improve this immediately.

Privacy and data protection

The problems addressed in the previous section naturally also have a direct impact on the data protection area. If valid phone numbers and the associated accounts can be determined so easily via the product, the privacy and data protection of the users is of course directly affected.

Apart from that, however, the product is rather inconspicuous in terms of data protection. Of course, a product in this category has far-reaching insights into the user’s privacy and these are also extensively used for data collection with the Xplora X5 Play. However, nothing else is to be expected from the outset. The privacy policy (as of October 2019) is not a prime example of transparency and detail, but it basically contains the most important points about data collection, storage and sharing. However, we still miss explicit naming of the included tracker modules and their used functionality here. In the same way, it would make sense to explain the necessity of one or the other of the 38 requested permissions in more detail. In addition, although the privacy policy mentions that, for example, collected data about the child itself is passed on to third-party providers for the fulfillment of certain unnamed services, which services and, above all, which service providers are explicitly meant by this is not explained in more detail. Of course, we never assume a deliberate lack of transparency here, but we could imagine that some users would have more confidence in the product if such information were presented in a less general manner.

Verdict

In principle, the Xplora X5 Play is quite a successful product: The applications are apparently technically cleanly implemented and the important topic of data protection and privacy is at least sufficiently well covered in formal terms. However, the partly glaring and nowadays completely unnecessary problems concerning the server API do not allow for a good rating. This is despite the fact that we have not even penetrated into the deepest depths of the Xplora solution in the context of the Quick Check. We recommend the manufacturer to improve this quickly and effectively – the problems are in no way unsolvable.

Following our test and prior to publishing this post, we informed the manufacturer about the found vulnerabilities. Xplora responded after the second request and promised to fix them as soon as possible. We gave the manufacturer a deadline of 30 days due to the relatively low effort required to fix the issue. An official confirmation by Xplora that the identified vulnerabilities have been successfully patched is still pending.