Snapchat - GibSec Full Disclosure

http://gibsonsec.org/snapchat/fulldisclosure/

by gulbrandr • 13 years ago

108 39 13 years ago

objclxt2• 13 years ago

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.

argonaut2• 13 years ago

According to my interview with them a few months ago, they're still running a Java stack on Google App Engine.

It bears noting that GAE is good enough for Khan Academy too.

objclxt2• 13 years ago

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.

a_olt2• 13 years ago

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.

j_s• 13 years ago

I thought it was just another snapchat api reverse engineering 'til I got to http://gibsonsec.org/snapchat/fulldisclosure/#obligatory-exp...

hamburglar2• 13 years ago

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.

gibsonsecurity2• 13 years ago

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.

optymizer1• 13 years ago

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.

a_olt2• 13 years ago

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• 13 years ago

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.

antics2• 13 years ago

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• 13 years ago

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.

kowdermeister• 13 years ago

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? :)

gibsonsecurity2• 13 years ago

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?

uptown• 13 years ago

On the subject of Snapchat - does anyone really believe that they don't permanently retain a copy of the images on their server?

zxcdw• 13 years ago

I doubt they want to store underage titpics.

circa• 13 years ago

i was going to say the same thing. hahah

JasonFruit2• 13 years ago

Shouldn't that be spelled with an 'x' or 'z' in it somewhere? I don't think you're maximizing the flippancy available to you.

js7• 13 years ago

I do. Why would they keep the pics? Unless they were legally obliged to?

dustywusty• 13 years ago

It's in their best interest to get rid of all photos posted to the service.

schiang• 13 years ago

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.

dave5104• 13 years ago

That feature was released on iOS a week (or so?) ago already. I haven't had a chance to play with it myself, though, so I'm not sure how it works.

tptacek• 13 years ago

ECB encryption. No MAC. Brand new system. Tell me again how developers should be building their own crypto?

yalogin2• 13 years ago

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!

xorbyte• 13 years ago

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.

sdevlin• 13 years ago

More importantly, all encryption keys are either fixed or stored directly alongside ciphertext.

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.

pencilo• 13 years ago

The key is a constant in the application, while ECB is embarrassing the mode can't help you here.

But if it makes you feel better you can upload arbitrary bytes to Snapchat, encrypt it with your own not-stupid method.

rohanpai• 13 years ago

What are the alternatives to EBC? Why not use CBC?

mukyu• 13 years ago

1 (note: it's still encrypted prior to gzipping).

why

Snapchat - GibSec Full Disclosure

Related Stories