Spying on old folks

We’ve tested plenty of kids GPS tracker watches over the years. Nearly all we looked at had critical security issues.

For a BBC show a while back we were asked to investigate the security of similar trackers for the elderly. They’re a nice idea; allowing people to live independently for longer and those with cognitive challenges can be traced if they wander off or forget where they live.

One that caught our attention was the Eview SOS tracker. Deral Heiland of Rapid7 had done some cool work on the tracker previously, though on the GSM and web app interfaces.

We were keen to see if there was anything up with the API.

Vulnerabilities

There is both a web and mobile app. The web app is found at http://smart-locator.com. Yes, plain text…

Anyway, whilst the web app does authenticate users, it doesn’t authorise requests in all cases, so a direct request as follows exposes user data.

http://smart-locator.com/web/main/xxxxx/tracker.html

Where ‘xxxx’ is an incrementing ID that exposes information regarding the tracker and user.

Then, if we look at API requests:

GPS locator request:

POST /web/main/editUser.html HTTP/1.1
Host: smart-locator.com
Content-Length: 110
Accept: application/json, text/javascript, */*; q=0.01
Origin: http://smart-locator.com
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/74.0.3729.157 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Referer: http://smart-locator.com/web/main/5371/user.htm
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: sid=07bd41a3-dce5-4527-8166-66fa9428dd6a; locale=en_US; remember_me=false
Connection: close

userId=5370&userName=egw5&userEmail=egw5%40mailinator.com&gender=1&country=&address=&phoneNumber=&description=&parentId=0

‘parentId=0’ is highlighted. This is not part of the regular request, but it can be appended to the editUser.html request.

ParentId is an incrementing number and one can enumerate all usernames with that.

Then, if you edit a user and add it to another account, it moves its User Role with it on to the new Parent account.

One can also pass a parameter levelCode. This is a ‘dot delimited’ list of the users that can edit that user e.g. 0000.0002.0495.4808.

If this is set to an empty value, then no user would be able to edit that user.

Authorising all API requests correctly fixes these security problems.

What does this mean?

Fundamentally, anyone can trigger any function of any tracker, or access any trackers data.

Track any elderly wearer:

Whilst the GPS locations in the above plot weren’t that precise owing to lousy cellular data coverage at the time, it was still easy to figure out where the user lived and track them in real time.

It was also possible to delete and/or re-write their positions. This could cause panic by their carer.

Snoop on wearers:

Just like the kids GPS tracker watches, the device is effectively a mobile phone. Having compromised the account, we can now create a call to the phone that doesn’t trigger the speaker or the ringer.

Now we have a spying bug being worn by the victim.

Call wearers:

It’s also trivial to start a call to the wearer. The device will auto answer allowing a scammer to have a two-way interaction with an elderly and vulnerable wearer.

Disclosure & remediation

I dropped Tod Beardsley of Rapid7 a line to ask if they had any success with disclosing their earlier findings:

“we got a big fat nothing from eView” was his swift reply!

So, imagine my surprise when I had a reply to an email to ‘[email protected]’ 14 minutes after I mailed them.

It was very refreshing to find a vendor that actually responded. They have clearly progressed in the two years since Rapid 7 had tried to disclose to them. The vulnerabilities were fixed within a week.

Whilst the lack of security was worrying, at least they took swift action when alerted.