[optymizer1]

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.

[antics]

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.

[eco]

> 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.

[antics]

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.

[a_olt]

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.

[mike_hearn]

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.

[dwild]

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.

[kowdermeister]

Totally agree. Documenting and discovering an API is far from calling it an exploit.

The document is also concerned about SnapChat's relationship with investors and the person of the founder, which is odd in a security paper.

GibSec's other work is another SnapChat analysis, which I find odd. Maybe he/she wants to work there? :)

[gibsonsecurity]

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.

Does that answer any questions?