Written by:

TL;DR

This blog post provides a technical description of how we discovered a backdoor in a smartwatch made for children. The device is a wearable smartphone, and the backdoor enables remote and covert surveillance through wiretapping, taking pictures, and location tracking.

The backdoor appears to be authored by the manufacturer of the watch, the Chinese technology company Qihoo 360. The watch is re-branded and sold to European and US markets by the Norwegian firm Xplora, who claim to have sold more than 350 000 smartwatches for children globally.

The backdoor itself is not a vulnerability. It is a feature set developed with intent, with function names that include remote snapshot, send location and wiretap. The backdoor is activated by sending SMS commands to the watch.

To trigger the backdoor, knowledge of a secret encryption key is required. Our research leads us to believe that the functionality cannot be used without knowledge of the key. However, as the technical run-through will show, there are several parties with the necessary access, including Xplora and Qihoo 360.

Qihoo 360 and the US government have a documented history, with accusations that include foreign espionage and imposing export sanctions.

All technical findings have been shared with Xplora and relevant authorities prior to publication.

 

Update 13.10.2020: Specified that the watch communicates directly with the Qihoo 360 domain 360.cn

Background

Children’s smartwatches are designed to enable parents to locate, track and communicate with their children. While they may look like a smartwatch, they are in fact and marketed as a child’s first phone.

The exact features and functions will vary amongst providers, but the primary functions typically include:

  • SIM card with 3G/4G connectivity, including a phone number
  • GPS for location data
  • Microphone and speaker for two-way audio communication
  • Camera for still images or video communication
  • An accompanying app for parents to locate, track and communicate with the smartwatch and child

Children’s smartwatches have had a checkered past, to put it lightly. In 2017, mnemonic worked together with the Norwegian Consumer Council on the #WatchOut project. The study investigated the data handling and security mechanisms of four children’s smartwatches that were popular at the time. The full report can be found here.

The investigation in general revealed serious gaps in security across the market. The most serious finding at the time was that it was effectively possible to take control over some of the watches. Hence, an adversary could find the location of a child, or communicate directly with the child through the watch without the parent noticing.

The project resulted, among other things, in:

Amongst the four watches included in the #WatchOut study was one produced by Xplora.

Who is Xplora?

Xplora is a line of children's smartwatches sold by the Norwegian company XPLORA Mobile AS (and XPLORA Technologies AS outside of the Nordics). Their watches are sold throughout the Nordics, UK, Spain, Germany, France and Poland, and from mid-September 2020, the United States. On their website, they claim to have sold over 350 000 devices and have more than 400 000 users, and in an interview with a local newspaper in 2019, they state that they had a turnover of over $9 million USD last year.

Since the #WatchOut study, Xplora is emerging as one of the leaders in their geographical markets, and expanding into new territories.

With this in mind, we thought it was a worthwhile endeavor to look at their updated model, the Xplora 4. In our previous assessment, our scope and focus was limited to the communication between the watch and the local servers, and the parental application. This time around decided to take a deeper look at the watch itself.

Xplora watch in box
The Xplora 4

Accessing the watch software

To figure out how the Xplora worked, the first thing we needed to do was gain access to its software.

Browsing through the menus on the watch revealed it was running Android Nougat, and that it had a Qualcomm Snapdragon Wear 2100 processor. As with any Android-based device, getting access as root is a good place to start. Root access would allow us to browse through the file system and look at the code it was running. With root, we would also be able set up a man-in-the-middle proxy and inspect its network traffic and communication.

Enabling root access on an Android device usually starts with modifying the file system. If we wanted to do this, a USB was going to be helpful. Though after a quick look at the USB cable that came with the Xplora, it was apparent we needed something different.

Cable and watch
The Xplora 4 with provided USB cable missing two pins

Some light soldering and two data lines later, we had a functioning USB cable.

Custom cable connect to watch
Modified USB cable

Qualcomm chipsets have an “EDL” mode, short for ‘emergency download’. Basically, this is a feature that allows manufacturers to flash new firmware to a device. It also conveniently allows you to download everything that is stored in the device’s flash memory. Using EDL mode we could take a snapshot of the device’s storage, inspect its contents, and make the necessary modifications to gain root.

We found that holding both buttons on the side of the watch forced it into Android’s fastboot mode. From there you could issue the “fastboot oem edl” command to enter EDL mode. Alternatively, there are special USB cables that can be used to accomplish the same task. A quick Google search for “edl cable” returns a number of options.

We used a somewhat interesting piece of software called Miracle Box that allows you to upload and download data through Qualcomm’s EDL interface.

Screenshot of Miracle Box
Screenshot of Miracle Box

After reading the flash storage, Miracle Box saves each partition as an individual file. These partitions can be easily modified in Linux with the standard mount utilities. Editing the build.prop file in the system partition allowed us to enable the Android Debug Bridge (ADB). It was as simple as uncommenting a configuration option left in by the watch developers:

#Set composition for USB
persist.sys.usb.config=diag,serial_smd,rmnet_qti_bam,adb

We uploaded the newly modified system partition, booted up the watch, and root!

Screenshot of code
Command Prompt showing root access

Investigating the apps

The next step was to start looking through the apps installed on the watch. Listing all packages with the “pm list packages” command returned a total of 90 applications. As you would expect, most were related to the Android OS or Qualcomm.

However, 19 of the apps were authored by the original equipment manufacturer Qihoo 360, the earlier mentioned technology company based in China.

It was a bit surprising to us that none of applications on the watch appeared to be authored by Xplora themselves. After some light research we discovered a nearly identical watch for sale in China, sold directly by Qihoo 360.

Screenshot of webshop
Screenshot of website selling a nearly identical watch in China

The watch sold directly from Qihoo 360 is branded as the “360 Kids Guard”. Googling this term results in pages of articles on the product dating back as far as 2013, and the watch brand is also mentioned in past Securities and Exchange Commission (SEC) filings for Qihoo 360 Technology Co Ltd.

A browse through the Terms of Service for the Xplora App also makes several references to a company named “360 Kids Guard Co., Ltd.”, including them being a data processor:

Screenshot of terms of service
Terms of service for the Xplora App

This led us to the conclusion that while Xplora had developed their own backend server infrastructure and parental companion app, the majority of the watch itself was developed by Qihoo 360.

Qihoo 360

Qihoo 360 and the US government have a documented history, with accusations that include foreign espionage and imposing export sanctions.

In June 2020, Qihoo 360’s Chinese and UK business entities (Qihoo 360 Technology Company and Qihoo 360 Technology Co. Ltd. respectively) were added to an export sanctions list by the US Department of Commerce, thereby placing restrictions on the companies from using exported US technology in their products. As documented in the official records from the Office of the Federal Register, it’s not revealed exactly why they were placed on the list, but the official wording is “there is reasonable cause to believe that these entities pose a significant risk of becoming involved in activities—the procurement of commodities and technologies for military end-use in China—that are contrary to the national security interests of the United States.”

Meanwhile in March 2020, Qihoo 360 published findings accusing the CIA of an 11-year espionage campaign against several Chinese industries. The report cites evidence of the CIA hacking toolset "Vault 7" that was leaked in 2017.

A backdoor for covert surveillance?

After poking around a bit, we noticed a suspicious looking package APTly named “Persistent Connection Service”. The application starts automatically at boot and iterates through all applications installed on the watch. As it goes through each application, it creates a list of intents that it can call. The Qihoo 360 code calls these “rules”.

In Android, intents are a messaging framework that allow one application to talk with another. Think about when you click a link on your phone, but somehow it magically opens Facebook. That’s done through intents.

Screenshot of code

The code above is part of the iteration process that builds these rules, and conveniently prints out debug information to the Android system log as it runs.

Screenshot of code

Reviewing the Android log, we can see that the Qihoo contact application has several intents related to wiretapping – namely WIRETAP_INCOMING and WIRETAP_BY_CALL_BACK. These have been added as rules to a component of the persistent connection service called the “command dispatcher”.

In essence, this part of the code is searching through the device to determine a list of possible commands it can call.

Now of course a command called wiretap got our attention. Further digging revealed a collection of suspicious, surveillance related commands:

com.qihoo.kidwatch

  • 134=com.qihoo.kidwatch.action.COMMAND_LOG_UPLOAD
  • 165=com.qihoo.kidwatch.action.REMOTE_EXE_CMD

com.qihoo.contact

  • 126=com.qihoo.watch.action.WIRETAP_INCOMING
  • 317=com.qihoo.watch.action.WIRETAP_BY_CALL_BACK

com.qihoo.kids.camera.activity

  • 320=com.qihoo.watch.action.REMOTE_SNAPSHOT

com.qihoo.kids.smartlocation

  • 303=com.qihoo.kids.smartlocation.action.SEND_SMS_LOCATION

If we wanted to run these commands, the next step was to figure out how to activate the command dispatcher. The Android manifest states that the application listens for several broadcast intents that get sent to a “CoreBroadcastReceiver” class. This seemed like a good place to look.

Screenshot of code
Screenshot of code
Code snippet that processes the received SMS commands

At this point we knew that the persistent connection service was collecting a list of possible commands, and that the command dispatcher was presumably capable of receiving commands and forwarding them along to different applications. The “com.qihoo.kidwatch.action.sms.command” intent filter in the manifest hinted that the SMS application was capable of sending commands to this command dispatcher, and that’s where we looked next.

Sure enough, the Qihoo SMS application has a “dispatchCommand” method that receives encrypted SMS messages, and if successfully decrypted, forwards them along through a broadcast message to the command dispatcher.

Screenshot of code
Screenshot of code
Code snippet that decrypts the SMS commands

To summarize, the command dispatcher iterates through applications and their intents, or commands. In order to call those commands, something needs to call the command dispatcher. The Qihoo SMS application can receive encrypted SMS messages that in turn call the command dispatcher.

Encrypted SMS > Command Dispatcher > Application commands (remote snapshot, for example).

Or in short – an encrypted SMS can be sent to the watch to trigger the surveillance functions.

Proof of concept - covert remote snapshot

Next was to put our findings to the test to find out if all this code actually worked. We decided to focus our efforts on the remote snapshot function. In order to do this, we needed a way to generate encrypted messages, and send them to our watch. We walked through the decompiled code to reverse engineer the syntax, and built our own command designed to trigger a remote snapshot from the camera application.

The SMS messages are RC4 encrypted with a four byte “hardcode” that’s stored in the NVRAM and set when the watch is manufactured. We were able to retrieve our own key by reviewing the Android system logs, and by using a Qualcomm tool called QPST to dump the NVRAM.

Screenshot of sms
The encrypted SMS command instructing the watch to take a secret picture

Sending the SMS triggered a picture to be taken on the watch, and it was immediately uploaded to Xplora’s server. There was zero indication on the watch that a photo was taken. The screen remained off the entire time.

Screenshot of captured traffic
Web traffic showing the photo being sent to Xplora’s server

Xplora now has a nice photo of our office ceiling sitting on their server.

Remote snapshot of ceiling
Picture taken with the remote snapshot functionality

Leveraging the backdoor

To utilize this backdoor somebody would need access to two pieces of information: (1) the device’s phone number, and (2) the factory programmed encryption key. Based on our observations we see a few plausible scenarios where somebody could get access to both.

Let’s start with the phone number, which is not particularly secret to begin with. Here are a few locations we believe it’s stored:

  • Xplora has the phone number on their servers.
  • We assume Qihoo has the phone numbers for the devices they sell directly, just like Xplora.
  • The phone company will certainly have access to this. In most countries this information is shared with law enforcement.
  • Depending on a few factors like your phone company and where you live, there’s a chance that your number has been published to public phone directories, such as the yellow pages, or similar.
  • You can get the phone number if you have physical access to the watch.

One noteworthy point to make is that we did not see Qihoo directly collecting our device’s phone number. Though we don’t necessarily think this means that they can’t, or don’t. During our tests we observed the watch communicating directly with Qihoo owned servers in China. The domains included:

p.s.360.cn
sdk.s.360.cn

This mainly appeared to consist of diagnostic reports, though some of this data was encrypted, or otherwise obfuscated. There was a large amount of code related to this reporting functionality and we were unable to thoroughly review all of it. It was not entirely clear to us what all this code was doing.

Xplora’s backend server is also interesting to consider here. The communication between the watch and Xplora was performed in a very unique manner, which involved encrypted JSON objects. The watch performed this communication with code developed by Qihoo.

Screenshot of code
Xplora’s proprietary communication protocol

It is a reasonable assumption that the server-side component receiving this data also has elements developed by Qihoo 360, however this was not within the scope of our research.

The second part to this puzzle is the encryption key:

  • Because the key is set during production, we can safely assume that Qihoo 360 has this key. This includes personnel at the factory where the watch was made.
  • We also observed that Xplora had the key, as it was used to encrypt traffic between the watch and their servers.
  • As we demonstrated earlier, if you have local access to the watch you can get the key.

In other terms, it isn’t exactly a limited group with access to these two puzzle pieces.

Final thoughts

There is no shortage of discussions that may be spawned from this type of finding, spanning IT security to ethics, geo-politics and beyond.

From an IT security perspective, the issue here is that this backdoor exists in the first place. This ability to issue wiretaps or take secret pictures over SMS is not a software vulnerability, a misconfiguration or an oversight in using outdated protocols. This is a functionality that has been created with intent.

What exactly is that intent?

To be continued…

 

Want to get in touch with mnemonic about these findings? Please reach out to [email protected].

Get in touch