Snapchat exploit may let hackers connect names and phone numbers in bulk

Status
Not open for further replies.

gütch

Well-known member
63
Gibson Security has documented the Snapchat API quite nicely. Maybe we'll now see some new, interesting Snapchat client apps?

Presumably the first feature such apps will add is the ability to keep things permanently. Not necessarily a bad thing: better that everyone can do it, rather than perpetuate a misconception that things they post to Snapchat can't come back to haunt them.
 
Upvote
6 (6 / 0)

Mitlov

Ars Legatus Legionis
13,016
[url=http://meincmagazine.com/civis/viewtopic.php?p=25928371#p25928371:tufuoxue said:
gütch[/url]":tufuoxue]Presumably the first feature such apps will add is the ability to keep things permanently. Not necessarily a bad thing: better that everyone can do it, rather than perpetuate a misconception that things they post to Snapchat can't come back to haunt them.

My prediction is that when people realize that Snapchat isn't guaranteed-temporary like they hoped, the entire service will collapse. The primary selling point of Snapchat over other social networks/services, it's entire raison d'etre, is the impermanency.
 
Upvote
12 (12 / 0)
Maybe I'm missing something, but it doesn't look like they've actually "exploited" anything? They've just documented the API the Snapchat client uses to interact with the server.

The proof-of-concept exploits they posted just automate things that would otherwise be very time-consuming, like searching for accounts by phone number (which you ostensibly might want to do after you join, to find people you know on the service) and sign up an account. These "exploits" are easy enough to stifle with rate limits.

None of this is on the "fetch private account data with public information" level of seriousness.
 
Upvote
3 (4 / -1)
Its typical that coding in and constantly checking for security vulnerabilities is relegated to the back burner of app development, which can make it all the more difficult to add back in later.

No one thinks its sexy to work on. And adding security features that you can exactly promote isn't attention grabbing.

Now Snapchat can choose to act like a $4billion dollar company that it thinks it is and grow up and make security ita first priority. Because security is the foundation of its relationship with its customers. When trust is lost, whooooosh!
 
Upvote
6 (6 / 0)

gibsonsec

Seniorius Lurkius
1
[url=http://meincmagazine.com/civis/viewtopic.php?p=25928579#p25928579:360gut1c said:
verbalcontract[/url]":360gut1c]Maybe I'm missing something, but it doesn't look like they've actually "exploited" anything? They've just documented the API the Snapchat client uses to interact with the server.

The proof-of-concept exploits they posted just automate things that would otherwise be very time-consuming, like searching for accounts by phone number (which you ostensibly might want to do after you join, to find people you know on the service) and sign up an account. These "exploits" are easy enough to stifle with rate limits.

None of this is on the "fetch private account data with public information" level of seriousness.


You'd be surprised how *little* time it takes, if you read further into it.

It's pretty damaging

//
Another good example is, how would you like it, if (for example), your daughter has Snapchat, and I was trying to stalk her, and I used an exploit like this to obtain her phone number, and from that her address.

Pretty bad, right?
 
Upvote
3 (5 / -2)

foxyshadis

Ars Praefectus
5,087
Subscriptor
The authors of this exploit actually went "full-disclosure" six months ago when they first published the API, saying there was an easy way to associate account names back to phone numbers without telling how. The difference here (aside from adding support for the useless new "privacy" settings) is that they wrote a sample script to do it, but it's really only one obvious step that anyone could have seen. With botnets, even rate-limiting probably wouldn't be useful.

By now someone has probably already cataloged the entire area codes of all the big cities. I wonder how 212 compares to 503 or 405, for instance?

Their home-grown manner of creating an auth key is baffling, when tools like bcrypt and scrypt already exist. I'm sure that it'd be nearly impossible to reverse-engineer from a black box, but one quick disassembly of the client that's freely handed out and the whole algorithm is right there. A good example of putting security effort into solving the wrong problem.
 
Upvote
5 (5 / 0)
Blocking scrapers or implementing a sophisticated DoS detection scheme seems a little orthogonal to the security of the api.

If they had an anti scraping layer in there, it seems like the api would otherwise be identical. A bad guy and a good guy and a bad guy are calling the api in the same way. The only difference is the frequency of calls it sounds like.

Nothing Gibson seems to point out seems to be a fundamental api design flaw, but rather just a missing block in the overall service. Most every other web service does this the same way. Blocking 3rd party clients isn't cool IMO, and is only an arms race anyway.

Or did I miss the memo that writing a straightforward scraper is an exploit these days? I guess people have gone to jail now for scripting curl..
 
Upvote
0 (0 / 0)
Status
Not open for further replies.