Skip to content

Instantly share code, notes, and snippets.

Created January 3, 2014 01:38
Show Gist options
  • Save anonymous/8231005 to your computer and use it in GitHub Desktop.
Save anonymous/8231005 to your computer and use it in GitHub Desktop.
Gibson Security (aka GibSec, GibsonSec) statement on the latest snapchat blog post Follow our twitter (@gibsonsec) or email us at

#####Gibson Security (aka GibSec, GibsonSec) statement on the latest snapchat blog post.

Follow our twitter (@GibsonSec) or email us at

In your blog post, you made a couple statements and you left a few things out, we want (on the behalf of the Snapchat user base) a few things cleared up:

A security group first published a report about potential Find Friends abuse in August 2013. Shortly thereafter, we implemented practices like rate limiting aimed at addressing these concerns. On Christmas Eve, that same group publicly documented our API, making it easier for individuals to abuse our service and violate our Terms of Use.

But is the exploit patched? I wouldn’t want to test, because I might get told “abusing” the service. A phone number, real name (most snapchat usernames i’ve seen have a full name in them) and location (whitepages and the area code) can get you pretty far when you’re social engineering a phone providers support. I’ve heard of SSNs being stolen with very little information from these people.

So I know some people don’t care if their mobile phone is public, but a lot of people want privacy, and we have seen that various people have had to change their phone numbers (which usually costs money, correct me if i’m wrong).

Last time we checked, Snapchat implemented some heavily flawed rate limiting on the find_friends function, which means that anyone, with a minor change to the code, can continue using the exploit.

We will be releasing an updated version of the Snapchat application that will allow Snapchatters to opt out of appearing in Find Friends after they have verified their phone number. We’re also improving rate limiting and other restrictions to address future attempts to abuse our service.

We’re not the first people to reverse engineer some of Snapchats protocol, we just created the most extensive documentation. Several people before us did some research and at no point were they met with this level of impoliteness. In fact, we think that you abused the trust of your user base by failing to respond to this situation with a swift response, we are yet to hear of what the users/people included in the leak have to do now, and at no point did I see an apology to the user base.

Is this address book function really necessary? Is it worth still having in your app? I’d do some research.

We want to make sure that security experts can get ahold of us when they discover new ways to abuse our service so that we can respond quickly to address those concerns. The best way to let us know about security vulnerabilities is by emailing us:

As happy as we are that you guys did listen to what we said and created a security email, we’re pretty disappointed that Micah Schaffer didn’t contact us back (28/12), as the SnapchatDB leak would not have been as severe or it could not even have been released at all (due to being too tedious), if we worked together to fix the vulnerabilities that exist in your application.

Anyone, Snapchat included, is welcome to email us at for any further questions, if we do not answer your questions on /r/netsec or HN.

Also, I wrote this in a bit of a hurry, so it have some errors, I apologize in advance.

OH, Did you guys address the Goldman Sachs stuff we touched on in our Christmas release??

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment