Snapchat - GibSec Full Disclosure
gibsonsec.org
gibsonsec.org
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.
It bears noting that GAE is good enough for Khan Academy too.
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.
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.
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.
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.
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 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.
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? :)
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?
The cryptography in this system seems to be 100% cosmetic, so I'm not sure things like ECB mode or absence of MAC really matter.
EDITED for clarity.
But if it makes you feel better you can upload arbitrary bytes to Snapchat, encrypt it with your own not-stupid method.
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.
"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.
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?
why