What's interesting to me is how the passage of time seems to have affected how Snapchat responded to this.
About twelve months ago I found a very similar vulnerability in SnapChat that could be used to provide a cellphone number for any given username (it was probably slightly more serious than what Gibson found, it was far easier to exploit).
Anyway, I ended up guessing Evan Spiegel's e-mail address along with a few other SnapChat staff and got in touch with them. They responded in twenty four hours, patched it, and we had a brief chat about how I ended up finding it in the first place. This was back when the API was still running on Google App Engine (...maybe it still is, although that would be surprising). I got the impression it was held together with string, but they engaged with me and it got fixed.
I would be interested to know how GibSec engaged with Snapchat, because their experience seems very different to mine, and yet the vulnerabilities are very, very similar.
GibSec say in their disclosure that SnapChat still uses GAE, and argue that this will make attacks easier/faster due to the server being unlikely to bottleneck.
Oh, I'm sure technically it's good enough, it just seemed surprising from a cost perspective. It seems at the scale they're at it would be cheaper to run their own. But then again, perhaps given the money going in cost isn't something Snapchat have to worry about.
I hate to be that guy, but what's the big deal? Where's the full disclosure? It looks like they're just documenting the API, which is not really disclosing much. Anyone can fire up burpsuite proxy and inspect HTTP requests and responses from their phone.
Now onto their PoC. So they don't have rate limiting on some API requests. That's pretty dumb for a service with a public API, but in my experience, most websites don't limit requests rate, because it's always a "let's toughen up security" after-thought. I remember GAE having some anti-DDoS measures, so they may be relying on that while growing the business.
The bulk registering of user accounts is more serious though and could be easily fixed (to some extent) with a captcha. This may be worthy of a tweet, maybe. Instead, Gibson listed all of SnapChat's APIs, even though most of them were irrelevant to the PoC, and slapped 'Full Disclosure' on it.
This is high-school level security researching. We were finding the same 'exploits' in high school. You could probably find these with any service that's only starting out. Glad to see that's the best Gibson could do. If I were Snapchat, I'd fix the two issues and then thank Gibson for spending the time to create an API page for SnapChat.
This comment makes you sound both arrogant and uninformed. You should rethink your tone.
First off, security exploits are not measured in how hard they are to pull off, they're measured in overall impact. This is because the point of security is to prevent such exploits, not to wave your dick around like an idiot. The point of this post is that there are very serious exploits in the service. That justifies the post being on the frontpage regardless of how hard they were to find. (Hint: the fact that you call it a "high school" exploit does not negate the fact that it's a serious vulnerability.)
Second off, Snapchat had a long time to fix this and they didn't. Maybe you would have "just fixed it" but the fact that they didn't is also newsworthy and totally justifies this post being here.
> This comment makes you sound both arrogant and uninformed. You should rethink your tone.
I see nothing wrong with the tone of the comment you replied to. The comment disagrees with the significance of the linked article and does so with examples explaining why they believe that. They could be wrong but it's hardly arrogant.
Your tone, on the other hand, is inexplicably combative.
The original comment says things like "anyone" can do this, and it's a "high school" level exploit.
The discussion is about security vulnerabilities. Comments berating the people who worked on this because they didn't pick a problem that's manly enough are completely irrelevant to the discussion at hand. They only serves to reaffirm the commenter's belief that they are smart.
Furthermore, while it is obvious the commenter doesn't believe the article is worth discussing, they certainly did not give good reasons for believing this. The whole comment is basically making the point that the summary is too elementary to be taken seriously, which ridiculous enough to deserve someone calling it out -- if it's so elementary, then why wasn't the find friends problem fixed? That only strengthens the case for this article.
You are disregarding the fact that the vast majority of attacks ARE, in fact, this simple. And your post also fails to mention what is central to Gibson's disclosure, namely the instructions for finding the phone-numbers of SnapChat users. So your post sounds really biased.
That's not an "exploit", that's just how all these services work. For a large service there really isn't a good way to implement private set intersection as would be required for this - all the techniques that might work are deep into academic-paper-only territory, forget about finding a convenient open source implementation lying around on github, let alone a mature one.
The other one, bulk registration of accounts, is also not an exploit using any conventional definition of the word. I spent years fighting bulk account signup abuse at Google. When we failed it was not an exploit in our system, because that implies you can provide some kind of cast-iron security guarantees on par with cryptography; you can't, all you can do is rate limit and try to detect bogus accounts. It's like finding a way to send spam and calling it an exploit.
The poor crypto is disappointing but hardly unique: the field of crypto in general has given people poor tools to work with. Things like NaCL are barely known where as lower level primitives are supported out of the box by basically every OS/platform out there, with little or no guidance on the best way to use them.
Are you really saying that it's not a exploit to be able to get a username from a phone number? They can bruteforce every single possible cellphone numbers (and they prove that it doesn't even take that long).
How is this not important?
Do you know what is a DOX? Do you know how easy it is to get one when you have some basic information about someone? With this new information you can now find a phone number based on their username... more information about someone = easier to DOX them.
The bulk registration is not really an exploit, you are right, but it's a good way to hide the other exploit as a new user. Yeah they don't actually have to hide it because even when they say they do it, Snapchat doesn't rate limit.
We don't :) (but we'd be happy to take Snapchats money and help them out!)
We documented two exploits, which are exploits, because we are exploiting code that has been incorrectly implemented.
We also noted that Snapchat must have lied to Goldman Sachs (is this what you were referring to?), as we noticed during our research that there is no mention of gender in the protocol.
This seems like a choice made by some one who knows what they are doing. They are using AES-CBC for the actual conversation but for media they chose ECB. Of course having the media deleted on the client is their main selling point and they chose to use ECB there!
But ECB for media is particularly egregious, particularly since even the Wikipedia page on ECB shows how remarkably 'visible' large things encrypted with ECB are.
It still seems a little overwrought. Given a phone number, you can determine whether or not that number is associated with a snapchat account, and you can get their username. Seems like a pretty mild disclosure (I'm having a hard time imagining any serious abuses of this information -- someone now knows your phone number and that you're a snapchat user, so I guess they can target some SMS spam at you if it's somehow interesting to them to target snapchat users...shrug). But it's a disclosure, nonetheless, and snapchat oughta fix it. Let's just keep things in perspective.
Also, it's laughable how wrongly GibSec estimated how long it would take to scan the entire snapchat userbase with this technique. "Let's see, they have 8e6 users and we can scan 6666 phone numbers per minute, so we can scan their entire userbase in 8e6/(6666 x 60) = 20 hours." Wrong: you aren't scanning 6666 users per minute, you're scanning 6666 phone numbers per minute, most of which are going to be misses. You're off by several orders of magnitude.
Sorry about that - I thought it was clear from the context of those off-the-cuff estimations that it was 6666 numbers (since that was based off of how many numbers you could scan, not users).
We've added some clarification just to be sure, thanks.
Just checked and you still have this completely broken paragraph:
"Given user_base = 8,000,000, and a numbers crunchable per minute (ncpm) of approximately 6666, we can assume that it would take approximately 20 hours for one $10 virtual server to eat through and find every user's phone number (hours = user_base / (ncpm*60)). At our worst case of ncpm = 5000, it would take approximately 26.6 hours."
Look at it this way: If they only had 5000 users, would you estimate the time to find all their phone numbers at 1 minute? No.
It's not flippant. There have been criminal charges brought against people sharing photos of topless underage kids obtained via Snapchat. This is not something Snapchat wants to have lying around. http://arstechnica.com/gadgets/2013/11/ten-boys-arrested-for...
Do the staff of Snapchat understand their legal situation? What do the laws of wherever their servers are say about transient storage (for caching, serving, etc) of images of nude under age people?
I read somewhere that snapchat is thinking about allowing users to replay 1 photo/video per day. They're pretty much telling everyone that they're storing these pics/videos with that feature.
About twelve months ago I found a very similar vulnerability in SnapChat that could be used to provide a cellphone number for any given username (it was probably slightly more serious than what Gibson found, it was far easier to exploit).
Anyway, I ended up guessing Evan Spiegel's e-mail address along with a few other SnapChat staff and got in touch with them. They responded in twenty four hours, patched it, and we had a brief chat about how I ended up finding it in the first place. This was back when the API was still running on Google App Engine (...maybe it still is, although that would be surprising). I got the impression it was held together with string, but they engaged with me and it got fixed.
I would be interested to know how GibSec engaged with Snapchat, because their experience seems very different to mine, and yet the vulnerabilities are very, very similar.