Show HN: Snapception – Intercept all snapchats received over the network | Hacker News Reader

Show HN: Snapception – Intercept all snapchats received over the network

github.com

210 pointsthebradbain80 comments

Snapchat use ECB as the cipher mode of operation: https://github.com/thebradbain/snapception/blob/781ebb13cd7e...

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.

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... ?

Yeah, ECB is BAD.

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.

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.

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.

Was this relevant to the comment you replied to?

Yes, the point is that whether they use ECB or not makes no difference and thus can't be considered an "Oops" in this use-case.

ROT13, AES-ECB or some state-of-the-art crypto, it's all the same if the end-device needs to have the key to decrypt it anyway.

> Intercept and decrypt all snapchats received over your network

Somewhat misleading in light of:

> Anyway, for Snapception to intercept your snapchats, you must be connected to the computer via a proxy and have installed its CA

Interesting, nevertheless, because it exposes that:

> they use one, hardcoded key for all video and image encryption

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.

So? Everyone should know that. Just get a camera?

This has been reality for more than a year. In fact, i've been running a bot based off https://github.com/JorgenPhi/php-snapchat for the past 11 months.

it has over 5000 friends, and its popularity puts me to shame :(

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.

[1] https://www.owasp.org/index.php/Certificate_and_Public_Key_P...

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".

Yes, but they would be clued in because the SSL certificate wouldn't be valid unless they trust your CA.

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.

"Oh my GAWD MOM! YOU ALWAYS DO THIS! squeals hysterically"

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)

In fact, most users will behave this way, it's not exclusive to teenagers.

Pretty sure you can't hit OK on this one, it'll just hard fail.

If Mallory can install an arbitrary root certificate on Alice’s client, M can do nearly whatever she wants with A’s client.

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.

Remember the iOS SSL bug from just this year that resulted in a complete bypass of x509 certificate trust validation?

But snapchat updated its encryption just a couple of days ago: https://github.com/programa-stic/snapchat-decrypt

You will need the android id of the phone, which I don't think you can easily get as a man in the middle?

Ooh, I didn't even to think to test it on Android phones. This method works on iOS devices, however.

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.

Except for versions 2.2, it appears to be a random 64bit integer:

http://developer.android.com/reference/android/provider/Sett...

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.

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?

Really seems like more of a snapanopticon than a snapception.

Snapchat's supposed valuation at $10b while they appear to be completely inattentive to the security of their product is hard to reconcile.

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.

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.

Yes this applies when you haven't raised funding yet, maybe if you've just raised your A Series, but not if you're a billion dollar company.

Of course there are always security holes, but they should really not be that gaping.

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.

Where did the key come from? Leaked by the application or something else?

..edit, found out they hard coded the string as constant in the app, smh.

https://github.com/thebradbain/snapception/blob/master/snapc...

Oh lordy. I wonder if they eval() arbitrary input from users as well.

Developer here — I think I recognized I had written some hastily written code in the bottom of my repo. Please, feel free to submit a pull request.

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.

Don't worry about it. I made a system call using process.call() and thought maybe that's what you were referring to.

What other bad practices should we be looking for ;)

Standard disclaimer applies: Code is dangerous, yo. ;)

The only "news" here is that you can MITM HTTPs when you own a trusted CA.

Of course you can break Snapchat if you can get users to install your CA cert. Snapchat is no different from every other application in that respect.

lol1 @ using a single key to decrypt everything; lol2 @ not using certificate pinning

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.

Doesn't seem to work. It's catching traffic but the snaps directory is empty.

If you can man in the middle traffic, aren't all authentication cookies compromised anyway?

Wouldn't any service then be subject to "interception"?

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.

Correct. Properly set up TLS should protect you regardless of MITMs.

The issue comes if someone can get you to accept their CA. In both this case and for MITM attacks on TLS. At that point it's game over.

There are trusted software client things (Spotify, Netflix, etc.) that seem to work well enough. Snapchat should be able to do better.

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.

[1] http://moyix.blogspot.de/2014/07/breaking-spotify-drm-with-p...

[2] https://www.usenix.org/node/182951

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.

quick heads up, on http://bradba.in under Technical skills > Web Frameworks you've put Node --- Node is NOT a framework it's a platform

Technically a misuse of the -ception meme.

Interception? Seems like a reasonable use to me.

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)*/.

A popular use, as you say, since 2010. But more popularly in use for centuries in words like perception, exception, deception, contraception, etc.

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.

Intersnaption?

I too thought of Intersnaption.

Snapper?

Snagchat?

Pretty sure they were going for a contraction of Snapchat interception.

Yeah, that's a misuse. It should be something along the lines of "a blank within a blank".

"interception", not "inception".

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.

Man, I was hoping it was written in C, or at least C++, not Python.

Out of curiosity, how come? Python runs on pretty much any platform you'd want to use and is much easier to develop in than C/C++.

I was hoping to see low level socket programming, you know, connect, close, open, bind, accept, recvfrom

All of those system calls are available in Python, FWIW.

https://docs.python.org/2/library/socket.html

Would certainly be overkill given the purpose it serves. A clean scripting language makes much more sense here for general consumption.

As a die-hard C programmer.

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.

Right tool for the right job and all that...

Reply on news.ycombinator.com