Sophos Cloud Optix
An Indian researcher has put Tinder’s online security in the spotlight again.
Last month, we explained how missing encryption in Tinder’s mobile app made it less secure than using the service via your browser – in your browser, Tinder encrypted everything, including the photos you saw; on your mobile, the images sent for your perusal could not only be sniffed out but covertly modified in transit.
This time, the potential outcome was worse – complete account takeover, with a crook logged in as you – but thanks to responsible disclosure, the hole was plugged before it was publicised. (The attack described here therefore no longer works, which is why we are comfortable talking about it.)
In fact, researcher Anand Prakash was able to penetrate Tinder accounts thanks to a second, related bug in Facebook’s Account Kit service.
Account Kit is a free service for app and website developers who want to tie accounts to phone numbers, and to use those phone numbers for login verification via one-time codes send in text messages.
Prakash was paid $5000 by Facebook and $1250 by Tinder for his troubles.
Note. As far as we can see in Prakash’s article and accompanying video, he didn’t crack anyone’s account and then ask for a bug bounty payout, as seemed to have happened in a recent and controversial hacking case at Uber. That’s not how responsible disclosure and ethical bug hunting works. Prakash showed how he could take control of an account that was already his own, in a way that would work against accounts that were not his. In this way, he was able to prove his point without putting anyone else’s privacy at risk, and without risking disruption to Facebook or Tinder services.
Unfortunately, Prakash’s own posting on the topic is rather abrupt – for all we know, he abbreviated his explanation on purpose – but it seems to boil down to two bugs that could be combined:
- Facebook Account Kit would cough up an AKS (Account Kit security) cookie for phone number X even if the login code he supplied was sent to phone number Y.
As far as we can tell from Prakash’s video (there’s no audio explanation to go with it, so it leaves a lot unsaid, both literally and figuratively), he needed an existing Account Kit account, and access to its associated phone number to receive a valid login code via SMS, in order to pull off the attack.
If so, then at least in theory, the attack could be traced to a specific mobile device – the one with number Y – but a burner phone with a pre-paid SIM card would admittedly make that a thankless task.
- Tinder’s login would accept any valid AKS security cookie for phone number X, whether that cookie was acquired via the Tinder app or not.
We hope we’ve got this correct, but as far as we can make out…
…with a working phone hooked up to an existing Account Kit account, Prakash could get a login token for another Account Kit phone number (bad!), and with that “floating” login token, could directly access the Tinder account associated with that phone number simply by pasting the cookie into any requests generated by the Tinder app (bad!).
In other words, if you knew someone’s phone number, you could definitely have raided their Tinder account, and perhaps other accounts connected to that phone number via Facebook’s Account Kit service.
What to do?
If you’re a Tinder user, or an Account Kit user via other online services, you don’t need to do anything.
The bugs described here were down to how login requests were handled “in the cloud”, so the fixes were implemented “in the cloud” and therefore came into play automatically.
If you’re a web programmer, take another look at how you set and verify security information such as login cookies and other security tokens.
Make sure that you don’t end up with the irony of a set of super-secure locks and keys…
…where any key inadvertently opens any lock.
