Why can we still crack snapchat photos in 12 lines of Ruby?
security.stackexchange.comI don't totally see the point to these arguments. The inherent nature of the technology we have means that if they can view it once, they can view it as long and as many times as they want. Anything trying to restrict that is just futile -- look at DRM.
Snapchat has never given that particular illusion of privacy. As the most common and basic example, it has absolutely no way of stopping people from simply taking a screenshot of your image. Snapchat is meant to be used to share throwaway photos without the social expectation that comes from putting it on somewhere like Facebook. Anyone who uses the application learns quickly that someone can potentially store the photo they sent -- in a vast variety of ways.
What the people who don't use Snapchat don't realize, is that you still have to trust someone if you're sending compromising photos. The benefit to Snapchat is that you don't have to worry about the recipients future negligence exposing them.
Snapchat is not a replacement for trust.
Actually it does attempt to do that - it requires you keep your finger on the screen while viewing so you can't perform whatever the screenshot command is. Which is lame but that's not the point - their selling point is that they do claim the images are transient. I'll wager 90% of their traffic is images people would not want made public, and some of it will be technically illegal.
The benefit to the user is that it establishes a social convention. You are unambiguously asking your friend not to share something around. It provides enough technical protection to prevent people sharing in the heat of the moment. In that sense it is like a changing room curtain.
I would take that wager. It's far less focused on nudes and illegal stuff than you would think. Most of it is just silly dumb photos or those that don't warrant being shared forever.
Not quite. The description on iTunes specifically notes that the receiver can take a screenshot: https://itunes.apple.com/us/app/snapchat/id447188370?mt=8
What's the point of that? I just tried it, and I can take a screenshot fine with one finger on the screen.
It used to be that taking a screenshot briefly stopped the touch event, so it could notify the sender when you took a screenshot.
iOS 7 fixed that bug, but added an official way for apps to detect screenshots. I would guess snapchat has just hung on to their old interface out of tradition, since it still works. It just doesn't have anything to do with screenshots anymore.
Ah, that makes sense, thank you.
The point of it is to reassure unsophisticated users.
It also attempts to notify the sender if the receiver takes a screenshot of the message.
> I don't totally see the point to these arguments.
Yes and no. The encryption key is fixed? Why not use a session key that is (nominally) ephemeral to the running snapchat process at least?
> if they can view it once
I have a camera and a phone. I can record anything displayed on my phone forever regardless of technology, and so can a three year old. Especially for "sensitive" snapchats, the "analog hole" (aka: a human has to be able to view it for it to be visual communication) renders all these ideas moot. It has absolutely nothing to do with "clever" drm-like hacks.
I agree, I just hope the average snapchat user realizes that there's no guarantee the pictures they're sending can be archived forever (especially the younger users).
I never used the app though, and I just tried to go to their website to see how they communicate on this issue just to discover that snapchat.com doesn't contain a single description of the service. There's just a silly video on the frontpage (turtle fights? I'm not sure about the ethics of that) and links to download the app. It's crazy that something so new is already popular enough that they don't even need to explain what it is anymore.
That being said on both apple's and google's app stores the description of the app mentions that the user can make a screenshot and save the picture, so at least they don't try to hide this limitation.
Actually an Android app can disable screenshots, but your point still stands: there is nothing to stop someone taking a photo of the screen.
It can, but they explicitly choose not to in Snapchat, afaik.
It's supposed to be hard enough for 99.9999% of users.
Forgive my ignorance, but why does SnapChat maintain a local cache beyond the 10-sec limit in the first place? Why don't they delete the photo and overwrite the disk space so that the photo is pretty much unrecoverable? Is it simply that this is too cumbersome to implement? Are there any technical restrictions? I tried Googling the issue and just came across the wave of articles that covered the discovery of the fact that photos were locally recoverable, but I don't seem to have found anything that indicates what motivated this design choice in the first place. Would be great if someone can shed light on this.
PS: I'm not a SnapChat user, so I admit that I might also be overlooking some functionality of the app that necessitates the use of a local cache
I wonder if you'd even have block level access to storage to pull that off through mobile APIs?
Well, it runs on Android? And you can compile your own kernel, and install google apps (or even run it in an emulator, anyway)... so... game over (wrt access to whatever is written to disc (or ram...))...
Unless there are COW mechanisms in place, simply pulling characters from /dev/{,u}random and scribbling over the original file should work well enough for the purpose of overwriting after the 10 second window.
This is a bit of a tangent, but I think it get's at the more interesting part of this question.
I ended up following a link to another sec.se thread where the idea of secure program obfuscation was discussed.[0] I feel embarrassed for having missed this but it appears that there exists on a theoretical level a manner of solving snapchat's woes.
The wired article ([0][0]) seems to suggest that it would be impractical at the moment due to resource constraints, however I also haven't had a minute to read the paper ([0][1]) yet as it is quite near morning and I need to get to sleep.
On a related tangent, the thing that sprung to mind about this new technique in obfuscation was the potential for using keyed APIs easily from the browser without having to bother the primary site's servers at all. Clearly very far away from there however.
Also, wouldn't secure obfuscation enable a lot of malware to evade detection by most current av programs?
[0][0]http://www.wired.com/wiredscience/2014/02/cryptography-break... [0][1]http://eprint.iacr.org/2013/631.pdf
While I agree that is amazing, it still wouldn't solve SnapChat's problem. Because once the image is decrypted and displayed to the user, you can easily copy it from memory and store it indefinitely.
Whitebox crypto, by itself, doesn't protect against this attack. What you end up doing is lifting the decryption code (wholesale, machine code level) from the SnapChat app and run that in your SnapChat decryption app. Your whitebox crypto code must now have anti-tamper defenses like hashing the rest of the SnapChat code to make sure it is there.
Not really, if the program looks sufficiently random it's probably malware. Don't forget false positives are ok as long as the user can decide to allow things to pass you can also flag programs as ok just as easily as you can flag them as malware.
I've worked with the unofficial Snapchat API a lot, and I've had the same thoughts. Basically Snapchat used AES ECB encryption with a symmetric key hardcoded into their binary. That's not a good idea, but its also better than nothing. Their api requests are all sent with a generated key parameter that takes 3 steps to make but really boils down to security by obscurity.
Snapchat made these security decisions long before anyone had any interest in "cracking" the app, and now I imagine they are looking for a way to get rid of this legacy code without breaking the millions of installed clients out there. It's an interesting problem and for now I'm having fun hacking on the API. If you're a Java person, check out my JavaSnap library which lets you send and receive Snaps.
I don't fully understand this issue.
I understand that you are never going to be able to stop the intended recipient keeping the image - that's trivial just with a screenshot, and anyone even capable / caring enough to run the linked code is going to defeat any further obfuscation you pile on.
What isn't clear to me from the link is: Is this same encryption the only protection applied to "snaps" that are in-flight? If I run my own wireless access point, can I use this code to decode all messages received by Snapchat users connected to my AP?
My understanding is, because they're kept on the disk, other apps can access them with no extra permissions - thus the reason they're "encrypted".
If you know the key, and because Snapchat will have to know where the files are, malware developers can write apps that scan the image directory, decrypt the files then send them to their own service.
Yes the same encryption is on in-flight snaps. You could absolutely set up something like that.
Well that's just awful.
As the answers suggest, there's a difference between encrypting everything with the same key, and encrypting between two parties.
Arguably, encrypting all snapchat traffic with the exact same key is almost worthless, and they could just send everything unencrypted. If a snooper knows they're looking at snapchat traffic, decrypting it is trivial.
At least with a key exchange, you have a good chance that only the targeted recipient can view the photo.
it is a bit disappointing that so many developers dive into making things without making some minimum research effort into what others have done before. its a recurring theme... however i'm torn because its nice that useful software can hit the market so quickly.
the usual piracy arguments are fine, and yes information that can be viewed by the intended recipient is necessarily crackable, but i think we owe it to our industry and community to not ignore the past X years of work in this field and implement embarrassingly naive amateur solutions. however it does require knowledge and effort to exploit this - particularly physical or close access to the device - imo no layers of security are not worth much once an attacker has physical access.
SnapChat is not alone - there are much, much worse offenders. That recent memory optimisation article about Firefox was imo considerably more shocking... browsers in general seem to be littered with amateurish crap. Even things like Office have some serious problems (why is this file locked? have you memory mapped it? do you need to actively stream my 1.2MB of excel file? really?) the Visual Studio devs have classically thrown away and rebuilt lots of good work over the last two iterations, whilst damaging the quality of the compiler - despite adding features. if valid code from popular libraries stops building between releases i wonder what regression tests are being done if any...
How would one solve this? One solution seems to be to generate key for each user and store the public keys on the server. If there is need to access the images on the server, encrypt them with a server key and then re-encrypt with the recipients' public key. Are there some problems with this approach (like some functionality of snapchat wouldn't work with this)?
You could improve (but not solve) the problem of raw access to data. But that does nothing wrt solving the "problem" of recipients storing a permanent copy of received snaps -- all they need is a camera.
It's a little like the old (tv series) adage of don't discuss crime in a car -- it's easy to place a bug in a car, so assume that it's bugged, if you have reason to fear someone's bugging you. Even if you're using encrypted phone/voip-chat -- that won't help squat if there's a microphone in the vicinity that can pick up both ends of the conversation...
> Are there some problems with this approach
More work. Since the users don't care about this breach anyway (which is why it hasn't been solved yet), it's not worth the developers' time.
I did not know about the "strings" command. I'm sure that there are plenty of binaries containing secret keys. I would assume that one way to protect against the easy prying ability of strings would be to use an integer array representing chars used to concatinate a string, but that does seem kind of hacky.
Cause we know the encryption key...
Because DRM is an idiot lie.