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?

Glorfindel
  • 2,263
  • 6
  • 19
  • 30
Dmitri DB
  • 1,181
  • 2
  • 9
  • 12
  • 2
    December, 2012: https://twitter.com/adamcaudill/status/285300559269994497 – Léon Pelletier Mar 09 '14 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 '14 at 00: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 '14 at 04:48
  • Cleaned up comments, removed soapboxing, reverted to actual on-topic question here. – Rory Alsop Mar 10 '14 at 09:46

9 Answers9

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.

kiBytes
  • 3,470
  • 16
  • 26
  • 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 03 '14 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 03 '14 at 16:35
  • I have a question. If there is a need for source code to have a password in it, how should this be secured? This is purely an example, but say there is an app that is using an API, and you don't want to expose your API key, yet you need to have it in the source code, because it is used. How do you effectively have a string that the user cannot retrieve yet can be used. Does not seem possible without asking the server for the string. – ComputerLocus Mar 04 '14 at 05:07
  • @Fogest That's a question in its own right. – SQB Mar 04 '14 at 07:19
  • @SQB I agree, that is a different question. – kiBytes Mar 04 '14 at 07:21
  • What I meant, is that it's an interesting question to ask. I hope @Fogest would like to elevate it from comment to question. – SQB Mar 04 '14 at 07:49
  • Hey! You can do it yourself! – kiBytes Mar 04 '14 at 07:53
  • Good question - http://security.stackexchange.com/questions/52693/how-can-one-secure-a-password-key-in-source-code – Peter Mar 04 '14 at 14:22
  • 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 05 '14 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 05 '14 at 14:10
  • @CodesInChaos I don't believe that is their goal. They know you can just use an external camera to take a picture. That's not the point of snapchat. The point is you're able to send your friends quick photos that aren't forever on facebook, etc. You can share things with a select group of friends in a quick and easy manner. You're not sending nuclear launch codes. You're sending a funny little picture. I honestly think they're doing enough. If you want to keep that selfie I took while pooping - go for it. – basher Mar 05 '14 at 14:52
  • 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 05 '14 at 20:38
  • 2
    @DmitriDB: I didn't miss that, it was entirely my point. Your question was "Why can we still crack snapchat?". Because they made it damn easy to. A better app would be to not store the JPEG at all (Why does it store it anyways?) – Engineer2021 Mar 05 '14 at 21:03
  • @0A0D Good points. I think that storing it in memory and only memory is less of an option, considering people tend to let their batteries run dry and such (*poof* gone forevers). I don't think only hosting it ~in the cloud~ for onetime access is a really viable answer either, considering video gets transmitted via this as well, and not everywhere in the world has reliable 3G/4G yet. Anyways, these are just my guesses as to the thought processes behind the dev of how things work here... Still waiting on comment from snapchat themselves if they suss up and join in on the convo here! – Dmitri DB Mar 05 '14 at 21:37
  • 1
    @DmitriDB: I don't use the app, but I have heard of it. If the point is to just send a silly photo that is viewable for a few seconds, then saving it is pointless. Unless there is a compelling reason to go back and look at them. Using a key to encrypt the package would be a moot point I think at that point. – Engineer2021 Mar 05 '14 at 21:38
  • 2
    @0A0D Again, people use it for beyond the point of silly stuff. It gets sexual sometimes. I feel sorry for people who are not of my generation using this, who don't get to have a little fun on that level... But I feel more sorry for the girls who have to put up with serious crap from naively trusting the wrong people. On one hand you could victim-blame them here and say it's their fault for doing that kind of thing in the first place, but really, we're facing up against the evolution of sexuality itself via technology here, and if we're not careful about it, i get the sense it'll go sour. – Dmitri DB Mar 05 '14 at 21:43
  • 2
    If you put anything online, you must assume it will be there forever. This includes pictures being transmitted over the internet between two mobile devices. Snapchat really should have a moral obligation to inform people that they are not preventing people from saving images, but rather merely attempting to make it more difficult. Also, it seems Snapchat was, and is, made by amateurs. Having the decryption key hard coded in the binary? Really? That's stuff we all stopped doing after taking our first coding class. – SnakeDoc Mar 08 '14 at 21:40
  • @DmitriDB _"I feel more sorry for the girls who have to put up with serious crap from naively trusting the wrong people. On one hand you could victim-blame them here and say it's their fault for doing that kind of thing in the first place"_ - Who are the "wrong people" here? Even if Snapchat was 100% secure in itself the photo still ends up on the screen where an external camera can capture it. Surely girls old enough to want to send intimate photos are old enough to realise this? – nnnnnn Mar 10 '14 at 01:03
  • 1
    @nnnnnn Surely, it's solipsistic to think that most people are as reasonable as you may pride yourself as being. Not that it's really our responsibility to reason for them, in any case, but I like SnakeDoc's suggestion that they should at least be warning people that there's no guarantee of the supposed ephemeral quality of anything here when it comes to the infinite echo chamber known as the internet, especially as far as it goes for their completely half-assed implementation of security. – Dmitri DB Mar 10 '14 at 04:38
  • @DmitriDB - I agree that a warning in big red letters the first time you use the app would be good just to make it clear to everybody. – nnnnnn Mar 10 '14 at 04:47
  • Nothing will prevent it from being completely secure, by the fact that I doubt there is actually a way to have self destructing non replicable code in today's phone, not a software implementation at least. On the other hand, they could have made the process a bit more annoying, so that only the most dedicated/knowledgeable could leak pictures. – Didier A. Mar 10 '14 at 15:31
  • Truth is, Snapchat doesn't give a sincere f\*ck. As long as they have their market share and nobody complains in a way that could damage their profits, they'll just keep reiterating their half a\*sed security policies and tell the laymen "such encryption, much secure, wow". They are not and never were committed to security and/or privacy. – Stefano Sanfilippo Feb 28 '15 at 10:58
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.

Philipp
  • 49,017
  • 8
  • 127
  • 158
  • 2
    +1 And snapchat was never intended to be secure anyway – wim Mar 05 '14 at 01:22
  • 1
    what if the architecture has tamper-proof parts? see [one time programs](http://link.springer.com/chapter/10.1007%2F978-3-540-85174-5_3) – Janus Troelsen Mar 05 '14 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 06 '14 at 08: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 '14 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 Chung Aug 05 '14 at 04: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.

  • 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 03 '14 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.

John Deters
  • 33,897
  • 3
  • 58
  • 112
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.

mckenzm
  • 487
  • 2
  • 6
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...

Lolol
  • 61
  • 1
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.

Drunix
  • 298
  • 2
  • 7
  • 2
    No one *needs* DRM. – AShelly Mar 05 '14 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 05 '14 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 06 '14 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.

TildalWave
  • 10,801
  • 11
  • 46
  • 85
  • 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 05 '14 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!

Dmitri DB
  • 1,181
  • 2
  • 9
  • 12