I'm one of the authors of Snapchat FS [1]. In order to build this, my coauthor Chad and I had to reverse engineer their API, which included decompiling the Android APK and snooping around for the call site of util encrypt.
While a lot of the security problems they have could indeed be fixed, I think it's worth noting a couple things.
* The Snapchat API is fundamentally insecurable as it exists today. The problem is not that Snapchat could have secured their API against unauthorized access and simply failed to do so, it's that their API cannot possibly be secured, AND they happened to make some bad mistakes along the way. Even a serious security team would have been unable to lock everything down. They might have locked some of these issues down, but they would not have gotten all of them.
* So, while I sympathize with the feeling that Snapchat is anti-OSS and anti-hacker, realistically, I also sympathize with Snapchat's position. They don't have that many options. What are they going to do? Their public position -- i.e., that you should not break their TOS -- does not strike me as especially unreasonable considering that investing millions into security will still not give them a bulletproof solution.
* Also worth noting is that Snapchat does not unilaterally ignore security inquiries, or at least, they did not ignore me. I emailed them personally and the response I got (from a high-level employee) was warm and encouraging. I did not get the cold shoulder. In fact, I found our interactions quite pleasant, and it made me want to help them lock things down.
Ultimately I think it's easy to write off the team as just a bunch of incompetent fools, but let's be realistic here: it's easier to break things than make them provably unbreakable.
Again, yes they've made some bad mistakes, but posturing about breaking a system that cannot be secured is perhaps not the best use of Gibson's obvious talent. The same also goes for the many other security researchers who've audited the API.
Hi, I'm one of the authors of the above release [1], and the exploit we primarily talked about (find_friends) isn't really an issue with the protocol as a whole.
We understand the need to support legacy clients, but Snapchat could easily limit the damage this exploit could do.
It wouldn't be that hard for them to make the best of what they have, by auditing all the code that typically has these exploits, and from that point onwards, also auditing riskier areas in the code base periodically.
But yeah, we have seen an improvement in some of the Snapchat client code, which indicates there are probably some bright new developers that have just joined the team. We just find it pretty bad that in this time, we haven't seen attempts (on our end, server side may be different) to secure the protocol.
Also regarding communication, we haven't heard a word from Snapchat in 4 months, neither has the reporter of this story, Violet Blue. If any of the guys from Snapchat are reading this (or you can pass on a message), tell them they're free to message us at security@gibsonsec.org.
Just saw your edit, the purpose of this release wasn't to tell everyone we're the nth person to reverse engineer Snapchats protocol, but rather to bring attention to the particular vulnerabilities.
I can speak for the rest of our team, and we're pretty sick of Snapchats protocol, and this will most likely be our last release regarding it.
Yeah, I agree with pretty much everything you said. I too think they could do a lot of things better. Yes, they've been really really slow to fix known issues. I did not mean to denigrate your work, which seems solid. :)
I'm just saying, 9 months down the road, if they had the optimal version of their security protocol, someone could still break in and write a post that "audits" it, just like we get every couple of months on the HN frontpage. Everyone would laugh, again. Some people would know that it's as good as it gets, but most people would just be in it for the circle jerk. There's no win for them here. That's all I'm saying.
*
Also, seeing your edit responding to my edit, sorry, I sometimes post before I work everything out perfectly. This isn't really an indictment of you guys specifically. I think your work is great.
Thanks, and that's totally fine. I agree with you, Snapchats definitely flawed from the start, but as long as we get rid of gaping holes in their security such as the find_friends exploit, at least they're halfway there.
(OT, but you have a really cool project list btw :P)
Offtopic - your name is confusing. I assumed you were Steve Gibson's spin-off into security, which is a poor association to have as he is widely considered an amateur in security matters. Very vocal and assertive, but an amateur nonetheless.
Sorry that really is a mistake on my part. I thought I saw his name attached to it. I'm probably thinking of someone else, again I apologize to all parties involved.
Yeah, I just dropped Bobby a note. I was like: "here's what I did", and he was like, that's pretty cool, how did you get in. And then I described the exploit. And then we had a short conversation about things they might have fixed that are easy to fix.
Teenagers and Kids use Snapchat mostly to share pictures, or did the target user base change, since I last heard about Snapchat? I recognize that this is a sensible topic, so it's really up on Snapchat to really do something now, for PR reasons, or to protect their users from potential damage.
I'll see if I can put it briefly. Maybe Chad will show up, he's much better at this than me.
The problem basically comes down to the fact that Snapchat needs to be able to discriminate between clients that are legit, and clients that are not legit. In other words, at some point Snapchat has to trust that it's distributing the server key (or cookie or whatever it uses in the future to allow clients to say "hey, it's me, you can trust me") to a legit client and NOT to a badguy client. This is not possible. Consider this issue taken to the extreme: even if you built Snapchat directly into the OS, and then signed, you could still root the phone and spoof the relevant parts of the OS to make it seem like you're a legit client when really you're not. Note that even pinning the cert doesn't work. You can still get around it by sniffing around the relevant buffers.
Spoofing the client basically guarantees that the API can be tricked into providing services that it was designed to avoid providing. For example, you can save all Snaps upon receipt. This is a trivial abuse. There are much graver implications that lead to much graver privacy concerns, but I hope you'll understand when I don't publicly announce them. :) Though perhaps Chris will tell you about them if you ask nicely.
First off I'd like to give props to the gibsonsec.org guys, that is a really high quality protocol breakdown and the attack is neat. I see nothing wrong with going full disclosure after being ignored this long.
The key point is to understand that I, as a protocol reverse engineer/attacker/professional bad dude have access to _everything_ the Snapchat app has. I own the network and the device the app is running on. I can look at every bit of Snapchat's memory space if I want.
I can view all network traffic between the app and the servers. Either by MITMing the app or if the app has cert pinning nothing stops me from peaking at buffers(I did this with Square, it was actually not that painful).
With just that you can see it is not possible to stop me from saving a Snap. I don't even need to make my own API calls, I can simply intercept the traffic of the actual Snapchat client and pull the image out of there. Even if you had a magical way to make sure only the actual app was requesting the Snap it wont help, it is the legit client.
The more important take away though isn't that Snapchat is broken, because that's not super interesting.
What you should take away from Snapchat is that you cannot stop people from calling your remote APIs that your apps are using. All it takes is someone sufficiently bored to go dig through pcaps and decompiled code to map out the API.
So what do you do? Don't trust the damn client. Your service shouldn't be broken just because I am calling your API outside of the bounds of how your application will call them.
This isn't a new idea, but it seems like a lot of people never learned this lesson.
Yeah, I mean, my major point is that Snapchat cannot deliver the services without trusting the client at some level, but that trust cannot be guaranteed.
I think the problem is that Snapchat is significantly less complex than a video game. With a video game, a cheater might benefit from something like removing the fog of war. So the server can just calculate that itself, and not tell you about things your client can't see. This makes cheating more difficult. (But of course, the game needs to be fast, so sometimes you have to give the client more information than it should display. In this space, room for undetectable exploits exist, and so there is a lot of complexity like spyware that reads /proc/mem to check if you're cheating. Or so they say, I've never read the source code...)
I've never used Snapchat, but from what I understand Snapchat basically sends people pictures with a time limit for looking at them. At that point, the client has perfect information, and it's up to the client to stop displaying the picture and remove it from system RAM, swap, CPU cache, GPU memory, and so on with 100% reliability after that timer expires, or the whole app is pointless. Since that's impossible unless you control every aspect of the system and encase it in self-destructing epoxy, the system is mostly pointless. (In that sense, it's like DRM. If you can view it, you can copy it.)
My understanding is that this is mostly used for sexting, which begs for me to ask this question: why are you sending naked pictures of yourself to someone you don't trust with naked pictures of yourself? Maybe work on those human relationships rather than outsourcing trust to some random company? Get off my lawn. Wheeze.
It's not meant to be secure, it's meant to be delete by default. Even without an exploit you can take a screenshot of the picture you receive.
However, defaults matter. Even if you're sending a private picture to someone you completely trust, if you do it by email or mms, they'll likely leave that picture lying around inadvertently for someone borrowing their phone to accidentally and embarrassingly stumble upon. With snapchat, the picture will be automatically deleted unless the recipient takes explicit measures to save it. THAT is the feature, not security.
It still has some use. I don't want to keep the photos of the lunch my sister just ate; she doesn't want to keep the image of the bread I just baked. SnapChat is handy for these kinds of things where people do not care at all about security.
Obviously, if people are sending nudes and hoping those images will never find their way onto the Internet it's a bit more worrying. I guess we should be persuading people to think carefully before sending nude images of themselves to other people. (And educating youth about the perils of nudes).
There is an important difference between what Snapchat needs and what game designers need.
First of all, look at what is actually successful for DRM in video games. The only surefire way to make sure someone is actually valid is to force them to authenticate(and get data from your server) to play the game. To do this they'll need to provide credentials(like a CD key) and then they'll get the content[1].
Now look at Snapchat. At no point do we need to fake having valid credentials. We are coming in and presenting valid credentials to Snapchat, my login and password, and it verifies those are correct and begins a sessions.
If you want an analogy to game DRM you need to look toward things like hacked clients in MMOs.
tl;dr Games want to prevent people without valid credentials from playing, we have valid credentials already(our own accounts).
[1] This is really simplified and you can find many games, like the new SimCity, that the server interaction is small and simply emulated in the crack.
Well find_friends exploit is one of them - my favorite was one found by clever/you [1] which leaked _any_ user's phone number because they weren't validating auth tokens correctly.
That's long since been patched, and rightly so - definitely more dire a situation than war dialing.
I have been following with their API changes since it's major update in early 2013, and anyone could have exploited the phone lookup function easily, because everything is there in the open. I was surprised by how easy it was to decompile the Android app:
public static boolean NEEDS_FUCKED_UP_NEXUS_422_SETTINGS()
Timber.d("Looks like camprevs gon hide dis shit", new Object[0]);
There really is no way for the Snapchat team to completely prevent others from reversing their API. A client is the endpoint after all. In order to make things difficult for hackers, they could do the following:
1. Implement a custom protocol over TCP/IP, kind of what Skype does.
2. Obfuscate the hell out of it and everything else.
3. Roll out new updates with both APIs.
4. After a reasonable amount of time, break backwards-compatibility on server side.
Hahahaha, I don't think making it harder to reverse would be any better, it would probably motivate people even more (deobfuscation is too much fun and fairly easy!).
They should really just focus on improving what they have and pushing clients towards a safer protocol slowly.
Snaps being stolen will always happen, but I do like the approach Instagram took to preventing spammers (getInstagramString(), it stopped everyone until they adapted!).
Yep, but at least that would be fun, don't you agree?
I also wonder why didn't anybody set up a Snapchat bot yet: it could successfully impersonate multiple humans by forwarding snaps between pairs of unsuspecting users, gathering a lot of data that way.
Actually, I know of one set up by a friend: snaproulettebot. You send a snap, and it sends you a random one back later from another user. Being called "snaproulettebot" makes it pretty obvious what it is, but you could do it in a more opaque way.
The user experience that has contributed to Snapchat's success is the ability to message with untrusted partner with constraints established by the central server and client. The biggest constraint is certain level of inconvenience in logging and redistributing the contents of the conversation.
Snapchat's business value could evaporate if clients that subvert the constraints on the user experience proliferated. The discussion seems to indicate that the technical barriers to this outcome are deeply inadequate. Snapchat looks like they are primarily going to use mechanisms to block the distribution channels of the Play Store and iTunes to ensure user experience integrity. This has the potential to fail catastrophically.
Why not just take a random sample of 5000 users and look at their snaps to determine if they're male or female? You won't be exact but you'll know if it's 70% women instead of 50%.
While a lot of the security problems they have could indeed be fixed, I think it's worth noting a couple things.
* The Snapchat API is fundamentally insecurable as it exists today. The problem is not that Snapchat could have secured their API against unauthorized access and simply failed to do so, it's that their API cannot possibly be secured, AND they happened to make some bad mistakes along the way. Even a serious security team would have been unable to lock everything down. They might have locked some of these issues down, but they would not have gotten all of them.
* So, while I sympathize with the feeling that Snapchat is anti-OSS and anti-hacker, realistically, I also sympathize with Snapchat's position. They don't have that many options. What are they going to do? Their public position -- i.e., that you should not break their TOS -- does not strike me as especially unreasonable considering that investing millions into security will still not give them a bulletproof solution.
* Also worth noting is that Snapchat does not unilaterally ignore security inquiries, or at least, they did not ignore me. I emailed them personally and the response I got (from a high-level employee) was warm and encouraging. I did not get the cold shoulder. In fact, I found our interactions quite pleasant, and it made me want to help them lock things down.
Ultimately I think it's easy to write off the team as just a bunch of incompetent fools, but let's be realistic here: it's easier to break things than make them provably unbreakable.
Again, yes they've made some bad mistakes, but posturing about breaking a system that cannot be secured is perhaps not the best use of Gibson's obvious talent. The same also goes for the many other security researchers who've audited the API.
[1] https://github.com/hausdorff/snapchat-fs