Reassuring Words and Good Intentions Don't Mean Good Security

How much can you trust the assertions made by an organisation regarding their security posture? I don't mean to question whether the statements are truthful or not, but rather whether they provide any actual assurance whatsoever. For example, nearly 5 years ago now I wrote about how "we take security seriously" was a ridiculous statement to make immediately after a data breach. It seems that not much has changed since then:

That last one is particularly apt here as it gets us on-topic with kids watches. Almost a year ago to the day, I wrote about a serious flaw in TicTocTrack watches that made it trivial to track kids, re-position them and even enable strangers to call their watch which would answer with zero interaction from the child. This wasn't the first instance of a tracking device on a kid going wrong, it was just the latest in a long line of them. To their credit, TicTocTrack rectified the flaw (insecure direct object references), communicated with parents and got back to business. Meanwhile, the whole kids-watch-security-train-wreck continued:

In that tweet, I concluded that "the pattern is alarmingly predictable" which foreshadowed what would inevitably be yet more incidents with yet more kids watches to come. TicTocTrack saw things differently:

The linked piece is titled "Cyber Resilience Key For iStaySafe" and is a short read wound up with a link to a PR company's email address. Amongst the reassurances of their investment in security is this paragraph:

In the following months, iStaySafe made significant investments both financially and by allocating staff resources to conduct a comprehensive penetration test of their software platform, mobile applications, sales website, all API’s and entire systems architecture. This investigation was conducted by a 3rd party C.R.E.S.T certified cybersecurity firm based in Brisbane to ensure that iStaySafe and subsidiary TicTocTrack has the best-practice cybersecurity and risk management protocols in place.

This is not at all unusual and it's from the same old "reassure customers of how seriously we take security" playbook. Many organisations assert precisely the same things: penetration tests, code reviews, ticks from certified bodies etc. A really key thing to understand here is that most of this is "point in time"; when the penetration test was conducted, everything was ok (or appropriately remediated). But the next day? Who knows. I don't mean to solely criticise TicTocTrack here, this is pretty standard PR which in my mind, didn't change a thing:

Sure enough, less than 2 months later, someone sent me my entire TicTocRecord pulled out via a flaw in their system:

[
  {
    "FirstName": "Troy",
    "LastName": "Hunt",
    "Email": "[redacted email]",
    "FamilyIdentifier": 3494,
    "PhoneNumber": "[redacted phone]",
    "ProfilePictureFilename": null,
    "CustomerType": null,
    "CRM_ContactId": "0",
    "ProfilePictureUrl": "https://tracker.tictoctrack.com/res/img/usermeta/DEFAULT_IMG.jpg",
    "ProfilePictureTimestamp": "0",
    "ProfilePicture": null,
    "ProfilePictureMIME": null,
    "Status": "Suspended",
    "ID": "[redacted email]",
    "CompositeID": "[redacted email]"
  },
  {
    "FirstName": "[redacted email]_temp",
    "LastName": "",
    "Email": null,
    "FamilyIdentifier": 3494,
    "PhoneNumber": "00000000000",
    "ProfilePictureFilename": null,
    "CustomerType": null,
    "CRM_ContactId": "0",
    "ProfilePictureUrl": "https://tracker.tictoctrack.com/res/img/usermeta/DEFAULT_IMG.jpg",
    "ProfilePictureTimestamp": "0",
    "ProfilePicture": null,
    "ProfilePictureMIME": null,
    "Status": "Temp",
    "ID": "[redacted email]_temp",
    "CompositeID": "[redacted email]_temp"
  }
]

Plus, they sent me my 7 year old daughter's record relating to her device:

{
  "DeviceName": "Elle",
  "DevicePhoneNumber": "+61473997091",
  "ICCID": "89610185002367820863",
  "IMEI": "357593061030345",
  "AlertPhoneNumbers": "",
  "AlertEmailAddresses": "||",
  "Avatar": null,
  "AvatarMIME": null,
  "AvatarUrl": "https://tracker.tictoctrack.com/res/img/usermeta/DEFAULT_IMG.jpg",
  "AvatarImageTimeStamp": "0",
  "DeviceTypeID": 4,
  "DevicePassword": null,
  "StaticMacData": "[]",
  "Active": true,
  "EffectDate": null,
  "AvatarImageName": null,
  "APN": "telstra",
  "SubscriptionType": "TTTSim",
  "ID": "3494|593061030345",
  "CompositeID": {
    "FamilyID": 3494,
    "DeviceID": "593061030345"
  }
}

Fortunately, that person was Gordon Beeming, a fellow Microsoft Most Valuable Professional who identified the vulnerability, contacted me privately, had the details passed on to TicTocTrack and then the flaw remediated before writing about it publicly a couple of weeks ago:

And the nature of the flaw? Take this URL:

/api/Users?$filter=(FamilyIdentifier%20eq%204236)

Now consider the filter in the query string and ponder: "what would happen if there was no filter"? Here's what Gordon wrote:

I thought what happens if I browse directly to that container without any filter, this pulled to my browser every user in their system

And that's how he ended up with every user in the system, including myself.

The point of all this is that despite the best of intentions (and I do believe their intentions are good), per the title of this post those good intentions and reassuring words do not mean that a security incident won't occur. Obviously, they also don't mean that one won't reoccur and any assertion to the contrary puts us back at the same November discussion in the tweets above (and we now know how that worked out).

So, should you not buy a kids tracking watch due to the inherent risks? I'm not saying that any more than I'm saying you shouldn't buy a connected sex toy; by all means, if one of these devices provides value to you and you're conscious of the privacy risks and willing to accept them, then do it. But for me, my own personal risk assessment puts a lot of weight in the old mantra of "you cannot lose what you do not have" so no, I wouldn't buy either.

Further to this, Jeremy Kirk has written about the incident today including comments from TicTocTrack on their decision not to disclose the exposure of their customer database in January this year. That's a bit tangential to the purpose of this blog post so I won't delve into it here, but leave your thoughts on that in the comments below. Here's their statement from the cyber resilience page mentioned earlier, just for context:

iStaySafe will continue to operate in an open, transparent and honest manner
Security TicTocTrack
Tweet Post Update Email RSS

Hi, I'm Troy Hunt, I write this blog, create courses for Pluralsight and am a Microsoft Regional Director and MVP who travels the world speaking at events and training technology professionals