Apps and Après. Skiing and privacy

Co-written with Chris Pritchard.

We were recently researching a job lot of ski and snow sport related hardware and software and discovered one app (of the many we reviewed) that gave us cause for concern.

In this particular case the vendor was helpful. There was no need to disclose it publicly as they had applied a fix within 48 hours of us contacting them.

However, there are useful lessons for everyone from our research, so here’s the anonymised version of our findings.

What we found

The apps main function was as a route tracker, so we were in familiar territory already.

Those oh-so common issues. As with many, many apps this one suffered from the usual glut of basic flaws:

• The email used to sign up wasn’t verified anywhere, so you could use anyone’s address.
• It allowed simple (read: easily crackable) passwords of 6 characters or more, so “password” or “123456” could be used for example.
• It did use HTTPS BUT if you requested information in clear text the app provided it back in clear text too, so you could read sensitive info like an email address.
• Although the application supported SSL it did not validate the server identity, leaving it vulnerable to MitM attacks. For this attack to be successful the attacker would need to be geographically close (i.e. in Wi-Fi range).

Now for some interesting issues

The app also had a group tracking functionality, so that users within a defined group of ski friends could see where the others were in real time with a map display. Pretty cool, easy to find out where your friends are without expensive ‘which piste are you on’ phone calls whilst roaming.

Wrong (you knew that was coming). When you create a group for your friends to join you can call it whatever you like, however, when adding friends to your group, the group creator passes them a unique 5 digit reference generated by the app. Uh oh…

The 5 digit group ID is generated server side. 100,000 combinations doesn’t sound like a lot of entropy, does it. Likely enough to cater for lots of skiing groups, but not enough to defend against a brute force or enumeration attack to discover valid group IDs

Once you’ve got a valid group ID, submit it in a POST request to the API and you can get information about the members of that group.

Worse, we found that with that POST request you could get every group member’s long/lat location information, in real time. You could also see when they’d created their account as well as when they’d joined the group. Their email address was disclosed too. Also, if they’d signed in with their Facebook account it returned their public Facebook ID so you could find their public Facebook page.

The icing on the cake was the apps persistence. If you didn’t explicitly close the app down it would keep running in the background, long after you’d left the slopes. Maybe so long after that it’d give your location away days/weeks after you’d got back from holiday.

Here are some screenshots of us tracking ourselves unauthenticated using the above bug… on the way from the ski slopes to the pub in Meribel!

Lessons that need to be learned

• Use email address validation.
• Where IDs need to be generated do so in a mathematically complex way. Simple sequential numbers can be easily guessed.
• Implement certificate pinning.
• Make it clear to users that the app continues to function unless explicitly closed down.
• Developers should be careful about the information they send back to anonymous requests. E.g. sending back email addresses and Facebook IDs. This could be a violation of the Data Protection Act.
• Use secure session management within your application. Ensure that only authorised users can make requests for specific groups.