To be fair, that demo only works on an uncompressed bitmap image with large areas of solid color. It relies on the fact that identical input blocks encrypt to identical outputs, leading to visible repeating patterns. In a format like JPEG, which has an entropy-coding stage and all kinds of internal headers, the chance of encountering two identical blocks in a file is miniscule.
Of course ECB is still a very bad choice, because there are plenty of other ways to attack it. But recovering Snapchat images without the key would not be nearly as trivial as that example might suggest.
I don't know a lot about the specifics of JPG file format, but... with a complex file format you can probably make some educated guesses about the content of some of the blocks and perhaps start building up a sort of dictionary... ?
To the extend that AES is a good random number generator, only if you have a complete dictionary of all blocks. Simply because a random number generator should produce independent output even if you only have a small perturbation in the input. That is, there should be no relation between a completely white block and an one where one of the pixels has a value of 0xfffeff.
Absolutely! There's no way I know to get at partial blocks where you have some knowledge, but even then you may have the start of some plaintext-leakage with the known-data and dictionary approach.
To protect in-flight data HTTPS encryption would be sufficient, since the attacker would have to MITM the connection and forge certificates instead of passively listening.
But once it reaches the end device it is impossible for snapshat to deliver on its promises of ephemeral messaging.
To display the data the device needs to be able to decrypt it. If it can be decrypted it can be copied.
It's very much the same conceptual impossibility that DRM faces.
So in the end it doesn't really matter whether it's ECB or something better. It remains a DRM scheme.
Not just that, but because it's a fixed key, and it's now known, there was no forward security. If you've been in any way able to collect pictures but not decrypt them, now you can.
Their point was, I believe, that you could store copies of all snaps sent to you without anything on your device which snapchat could "check" to see if it was being interfered with.
They could use certificate pinning [1] (and really, there is no reason for an app author not do so, except for the additional work) which would thwart all man-in-the-middle attacks. The end-point is still open through the analog gap (photograph of the screen) and custom clients, though.
Connecting via a proxy and installing a CA means this is more of a tool for a snooping parent to intercept the snapchats of their kids while they are at home, rather than a scary-looking tool for intercepting the general stream of snaps (as it is made out to be).
Not necessarily. If you control the gateway, it's possible to transparently redirect outbound connections into your proxy. I used to do this back in the 90s to force our employees browsers through an ad-blocking proxy. Depending on your user base (kids?), it could be as simple as setting up an open wifi access point in a place where all other APs are password-locked.
Edit: I just realized that this proxy requires the device users to load a CA cert. That makes things a little more difficult but still not impossible. Through creative social/software engineering, you might be able to persuade the users of your rogue access point to load the CA cert "in order to use this free service".
Have you met a teenager? They will blindly just click ignore/ok until they can do what they want. an invalid cert error isn't going to stop them unless it actually blocks (rather than warns and lets them proceed)
That's pretty trivial for parents. "Hey pumpkin, I need to borrow your phone for a second". That said this is something that maybe 0.1% of parents could or would set up.
Good point, but it's an interesting idea. An open-source home firewall that's designed with features/sniffers that lets parents keep an eye on their kids' online usage.
I was thinking the same thing. Call it Kidsafe or something. Make it automatically configure the router and let parents access the info online. Most phones are programmed to use wifi at home - seems like a promising opportunity.
I've been using the same setup locally for years - ad-blocking/page-rewriting proxy to MITM the browsers on my machine and filter parts of pages that I don't want to even reach the browser.
If Snapchat required each user have a separate public/private keypair (which would be transferred through other means, maybe even in-person), like what SSH uses, then they would be less amenable to being MITM'd via a single centralised trusted authority.
Or, perhaps, as a tool for an individual user who, for miscellaneous reasons, wants to store his or her received snaps for use later. Again, the point, as given by the author and expanded by me, is that the Snapchat system contains a large security vulnerability, and that it is foolhardy to believe that snaps you send will be gone as soon as the recipient sees them.
Well, that's for the encryption key of the images stored on the device. But if you can MITM the connection, then you can get the images as they come from snapchat to the device? And either the device have to send the id up, so the server can encrypt the images with a shared secret (perhaps the id is sent when the app is installed?) -- or the images are sent, encrypted with a different key, then re-encrypted for storage on the device?
What do the android ids look like? I'm assuming it's just a number, but I don't know how big. The page you linked to says the key is md5(android_id + "seems legit..."). It seems to me like this could potentially be brute forced to find the android_id using a captured encrypted image.
That would take some time to brute force I guess. Especially if the only way to check each guess is to try and decrypt and look for a valid (part of an) image header.
It is? Startups are taught to move fast and break things. Security usually requires to be thoughtful and not intentionally ruin stuff. Runs counter to the whole new modern movement.
Their selling point is that the snaps are ephemeral. I don't think anyone's expecting fool-proof security, but the overall impression is that the privacy aspect is all just marketing hype. It's not that big of a deal but then again it's not a big deal to switch to the next messenger app either.
I didn't think that facebook policy was industry policy.
Besides I always though that sounded like a bad idea as an aim, it is more just an observation of one of the common consequences of moving fast, which probably should be looked at and reduced by having some extra members of staff dedicated to breaking less things, so that moving fast doesn't get too expensive.
What's also really sad is that the FTC is actually on their case, but they're evidently in no capacity to throw their weight around enough to put a stop to this.
I think maybe I should've been more clear. I was referring to Snapchat's horrible security policies in that comment, it was not a criticism of your code.
I can't get this to work on my iPhone. When I visit mitm.it from my phone, or any other device, it redirects me to grit.io. How do I install the CA. I have the proxy up and running on my Macbook pro.
Not with proper encryption, I believe? In this case you can get someone else's supposedly private snaps if they're on your network, because the key is the same as the one for decrypting your snaps.
Totally different incentive. Spotify only needs protection that's enough of a pain the the ass to make it easier to just get the content from somewhere else or perhaps just pay the $n.99 for it.
Snapchat is full of (supposedly private) information that is not available anywhere else. Attackers will be far more determined.
See links for a bit of reading about how hard it is to break DRM on Spotify or Netflix. They're doing a lot more than Snapchat. The difference between "you just need to reverse engineer the HTTP API to make a 3rd-party client" and "you need to run IDA Pro and PANDA and whatever else" is significant. The latter exploit would have far less reach.
I read through the Spotify article, and if I understood it correctly, you don't need to run QEMU+PANDA to get at the unencrypted stream. That was just the method the author chose to analyze the running code. He tracked every memory read and write made by the CPU, and looked for byte distributions that looked like encrypted data, and found the decryption function at address 00719b84. He then located that code inside the Spotify binary, at 0x0042e2ed.
Once you know that, you don't need to repeat the initial analysis every time. You can just set up a hook to record all the data that flows through that function after it's decrypted.
Yes, that's my understanding as well; my other comment was sloppy. I'm unsure what was meant by "hook," though. Is that something you set up with the target process running under a debugger? That much privilege wouldn't be available to apps in an app store, right?
I meant "hook" in the most vague, hand-wavy sense of the word… anything from attaching a debugger at runtime, to modifying the binary so it automatically saves every song on your desktop. Obviously if you did something like the latter, no extra privilege would be needed.
It's funny that the word inception doesn't really mean what it does in the -ception meme. "The time at which something begins" is the dictionary definition. In the movie this refers to planting an idea in someone through dreams, NOT the idea of nesting things within other things.
At this point though I've heard it used in the other way that it may as well be an alternate definition.
As the developer, I was going for combining "Snapchat" with "Interception", and "Snapception" was the result. I wasn't even thinking of Inception at the time, an oversight on my part.
The -ception suffix is typically used for nested abstraction; for example running a virtual machine within a virtual machine could be referred to as VMception. This is in reference to the 2010 movie Inception, a major device of which is the use of nested dreams, or /a dream(?: within a dream)*/.
For tools and toys that are not performance sensitive, python is great. It's a lot more expressive and requires a lot less boilerplate code.
I've re-written projects from C->Python before and had them work with 30% the number of LoC. I've re-written projects from Python->C before and had a 10-fold speed increase.
To see why this is a problem, see the ECB-encrypted Tux image on http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation#...
Oops.