112

Just came across this bit of ruby that can be used to decrypt Snapchat photos taken out of the cache on a phone, apparently adapted from here. To my surprise, it worked without a problem, considering the problems around Snapchat's security which have been well publicized lately (Mostly the stuff around the whole phone number/username leak as far as I recall).

require 'openssl'

ARGV.each do|a, index|
    data = File.open(a, 'r:ASCII-8BIT').read
    c = OpenSSL::Cipher.new('AES-128-ECB')
    c.decrypt
    c.key = 'M02cnQ51Ji97vwT4'
    o = ''.force_encoding('ASCII-8BIT')
    data.bytes.each_slice(16) { |s| o += c.update(s.map(&:chr).join) }
    o += c.final
    File.open('decyphered_' + a , 'w') { |f| f.write(o) }
end

So, my question is, what exactly are they doing wrong here, and what could they be doing better in order to improve the security of their application in this regard rather than what they're doing now, considering that people often send intimate things that were never meant to be shared for longer than 10 seconds only to one person, and also considering the popularity of this app?

tldr/for all those who don't really care to know how computers work but still want to know what is up: Basically, let's say you have 40 million people who use Snapchat, with 16.5 million users sending each other pictures, and each picture in its own tiny locked safe every day. Now, what if you gave those 16.5 million people all the same flimsy, plastic key to open each and every one of these lockboxes to capture the Snapchat media?

Improve this question
4
  • 2
    December, 2012: twitter.com/adamcaudill/status/285300559269994497
    – Léon Pelletier
    Mar 9, 2014 at 18:05
  • @DmitriDB - Your introduction about the safes where everybody has the same plastic key that can open "each and every one of these lockboxes" implies you are talking about a way to hack into anybody's Snapchat photos. But the code you show relies on getting data from an actual individual phone, no?
    – nnnnnn
    Mar 10, 2014 at 0:55
  • @nnnnnn the 'key' in my watered-down explanation for the layman there referred to the 'tiny locked safe' that get sent off to each individual phone containing media. Some goon took it upon themselves to 'clean up' that watered down definition, complete with shitborked grammar, so I'm not really sure it's as clear as it used to be a this rate... But no, that's definitely not what it meant.
    – Dmitri DB
    Mar 10, 2014 at 4:48
  • Cleaned up comments, removed soapboxing, reverted to actual on-topic question here.
    – Rory Alsop ♦
    Mar 10, 2014 at 9:46

9 Answers 9

Reset to default
93

This is a serious problem in password-management. The first problem here is the way they managed his key in their source code. SnapChat states that they send the photos encrypted over internet, and it is true after all, but they are using a "pre-shared" key to encrypt this data (badly using also AES in ECB mode) so, every user around the planet has the key to decipher each photo.

The problem here is, how did internet get the key? Piece of cake, they just included it in every app, and somebody just searched for it.

What is this magic encryption key used by any and all Snapchat app?

M02cnQ51Ji97vwT4

You can find this (in the Android app) in a constant string located
in com.snapchat.android.util.AESEncrypt; no digging required, it is
quite literally sitting around waiting to be found by anyone.

On a more positive note (perhaps), in the 3.0.4 (18/08/2013) build
of the Android app, there is - oddly enough - a second key!

1234567891123456

It is a very bad practice to hardcode a password in your source (no matter if it is in your headers or in your binaries), the main problem being anyone could find it with a simple "strings" command into your binary (or by looking in someplace you used to share your code with your friends):

strings binaryFile

Then the malicious user can have a look to each string and check if that is the password he is looking for. So, if your really need to hardcode a password in your code you better hide it, but this will just be "security through obscurity" and the malicious user will end up finding the key (so you better think in a different approach).

What can they do to improve their security? Well they could have generated a key for each photo, or they can pre-share a key between the clients that are going to share a picture, public/private keys; there are plenty of options.

Improve this answer
22
  • 43
    The big problem is that their goal is impossible to solve - prevent the owner of the device from saving the picture. Still this is pretty weak even for a DRM scheme. More elaborate key management would improve the situation a bit, but not much. You can still take screenshots or hook an API through which the decrypted image gets rendered.
    – CodesInChaos
    Mar 3, 2014 at 12:53
  • 2
    Well, at least the screenshots tend to get captured with an notification when taken... At least when you take them with whatever conventional method (Press three buttons on the phone or what not). But yeah, all I can do is agree, it's weak stuff!
    – Dmitri DB
    Mar 3, 2014 at 16:35
  • 2
    You don't even need to take screenshots. Since it is viewable by your own eyes, use another phone, webcam, VCR camcorder, etc to save the picture. The app can't prevent that.
    – Engineer2021
    Mar 5, 2014 at 14:05
  • 2
    Heck, they could remove this vulnerability if they just deleted the downloaded images altogether. Wouldn't prevent the analog hole but if the app just stored it encrypted in memory, you would have to root your device and have another one running in the background to grab anything having to do with snapchat out of memory.
    – Engineer2021
    Mar 5, 2014 at 14:10
  • 2
    @0A0D &basher Well, this is my issue with your perspectives on how people use the app, and something you seem to have missed out on in my post here -- People are using this to send -intimate- photos. Kids who don't know any better, etc. These are getting leaked all over the internet, and now we have girls becoming unintentional pornstars. And no, the pervs who are leaking these photos are -not- using some goofy method with a second camera. They're using some clickmouse creep-apps which take care of things with dumbass-friendly ease due to this glaring hole. I get the sense this is preventable.
    – Dmitri DB
    Mar 5, 2014 at 20:38
82

Because this is a fundamental principle of information theory.

If a machine can decrypt a piece of information and keep it for ten seconds, it can decrypt it and keep it forever.

Any attempt to disguise this is simply smoke and mirrors.

Improve this answer
5
  • 2
    +1 And snapchat was never intended to be secure anyway
    – wim
    Mar 5, 2014 at 1:22
  • 1
    what if the architecture has tamper-proof parts? see one time programs
    – Janus Troelsen
    Mar 5, 2014 at 13:25
  • 13
    @JanusTroelsen from the abstract you link: "All these tasks are clearly impossible using software alone, as any piece of software can be copied and run again, enabling the user to execute the program on more than one input. All our solutions employ a secure memory device, inspired by the cryptographic notion of interactive oblivious transfer protocols, that stores two secret keys (k 0,k 1). The device takes as input a single bit b ∈ {0,1}, outputs k b , and then self destructs." As current PCs don't have such a secure memory device, no actual implementation of this is possible.
    – Jules
    Mar 6, 2014 at 8:27
  • @JanusTroelsen Nice link, it would be nice if PCs and Phones started including some more hardware level security that would allow for such things. In fact, the topic of self destructing digital content is a very interesting one.
    – Didier A.
    Mar 10, 2014 at 15:25
  • @didibus There is no such thing. Any hardware solution can be reverse-engineered; all you can do is make it harder.
    – lily
    Aug 5, 2014 at 4:58
46

The code is not "cracking" the encryption.

You are merely decrypting the data with the correct encryption key which was obtained by reverse engineering the application.

How could they do better? Not hard code the encryption key for one.

Improve this answer
1
  • 3
    @theGreenCabbage Classic example of security of obscurity in any case. If you want the receiver to be able to see the picture, the receiver can make a copy of it. At least if you have full privileges on the phone which really isn't hard to achieve. Heck make the picture fullscreen (no idea about snapchat but I guess they allow that?) and just make a screenshot - no big difference in the result.
    – Voo
    Mar 3, 2014 at 22:01
20

Because it's not supposed to be impenetrably secure. Snapchat is for sharing, which is antithetical to securing.

I think they have implemented what they consider to be "enough" security for their model. They aren't too concerned about photos lasting longer than a few seconds, because people can always copy them via the analog hole. This encryption prevents people from simply saving the files to show to their friends, so they have to do a bit of extra work. This simple step protects over 99% of their photographs well enough.

Improve this answer
8

By design. I do not think the number of lines is relevant. Nor do I think the language is relevant.

The question simplified is "Why can anyone decrypt these". The answer - because that was the intent.

The background is that the encryption may only be lip-service, in the same way that encrypted .pdf's are often sent with four letter dictionary words as passwords.

There is security, but it is circumventable at some token level of effort. The layperson has no clue. We know better. (We know that in a post Snowden world we cannot be sure we can trust SSL protected websites.)

In short, it is a plastic padlock to satisfy the promise of encrypted transmission.

Improve this answer
6

"So, my question is, what exactly are they doing wrong here"

That one is easy, they are promoting a false sense of security in people that are not familiar enough with the technology that they are willing to to trust sending information that would otherwise be considered private, to strangers...

That is the real flaw in the design.

Instead of making more convenient ways to do this, they should assisting in the raising of smarter generations, or just disclaimer the install so the self inflicted victims cannot cry foul.

There are solid, tried and true encryption and transmission methods for internet communications, and the end goal is that if you want security get security, if you want the chance of interception, redistribution, and poor coding practices, then download whatever is hottest on the app store this week...

Security is not convenient, it is generally not fun, and it is not simple. all the things that kill a fly by night app.

Personally I would be MUCH more concerned with the developer having access in mass quantities over individual attacks...

Improve this answer
5

The problem with snapchat is that they are doing plain crypto while in fact they need DRM. The latter involves more topics than simply encrypting your data, you need for example hide your keys from your user. It looks that they failed on this one.

Improve this answer
3
  • 2
    No one needs DRM.
    – AShelly
    Mar 5, 2014 at 18:25
  • 6
    DRM is about cotrolling what can be done with digital content, and this is exactly what snapchat promises and obviously fails to deliver. When you say that no one needs DRM, you probaly think of DRM safeguarding the interests of $BigCompany$ against probably legitimate interests of their customers. I think most of us don't like this application of DRM, but in snapchat it is about safeguarding the interests of users posting the images. Every scheme that keeps the promise that images are unavailable some time is controlling the usage of the image and therefore by definition DRM.
    – Drunix
    Mar 5, 2014 at 21:39
  • 1
    While I agree with you that the Snapchat model is not security so much as it is DRM, the same problem would still exist. It's not like DRM is some impenetrable thing that can't be cracked and stripped.
    – Mordred
    Mar 6, 2014 at 18:13
3

Bad practice combined with depreciated security standards have opened up this vulnerability. Especially given Snapchat's 'mission' of making the images, texts, etc. non-reproducible and only viewable once, a better approach would have been to randomly generate a PSK on every boot and use that for the duration that the app is running, rendering it's data useless upon every relaunch. And yes, as many others have said, hard coding a security key directly into an application's code is very, very bad practice and one that could be easily avoided.

Summarising, to easily resolve this issue:

Use a randomly generated string (and a better encryption algorithm, although this poor choice may be somewhat related to the lower processor requirements and the primary target audience [younger people] who are more likely to have dated smartphones) as SSL pre-shared key which cycles on every boot, rendering the cache useless upon app relaunch.

Very easy to resolve, really. Sounds like they could do with some consultancy around security best practices.

Improve this answer
1
  • Even so, if the image is transmitted in the clear over an unencrypted wifi or LAN, then it's still in the clear and ripe for the taking
    – Engineer2021
    Mar 5, 2014 at 14:02
1

So, I called snapchat out to reply to this question I've asked in their support, and got this instead. So, after a bit more than a few days, here is Snapchat's official reply to a support request with me linking to this post, and asking if they could weigh in with an honest reply to this question themselves. I personally consider this pretty much the weakest reply I could have gotten next to nothing at all, and an indication of dysfunctional regard of security practices and not to mention public relations:

Team Snapchat replied:
Hi Dmitri,

Thank you for sharing your concerns. We remain committed to maintaining 
the security and integrity of the Snapchat community.

Best,
Tobias

Thanks, snapchat!

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .