I have recently been digging through windows store apps in order to see what dumb things engineers are putting in the store. Recently, I found an ssl.pem file deployed with an app.

I never ran this app, so I don't believe this file was generated locally. I think they deploy it with the app. I just installed it from the Windows store and started digging.

My assumption is, with the ssl.pem file, I should be able to:

  • MiTM someone that is using the app
  • Feed the pem file to Wireshark
  • Decrypt and inspect all their traffic.

Is this a realistic attack? Is there something I'm missing?

Also, is it common to deploy an app with a pem file inside? I would imagine you'd want to generate that on a per session basis.

  • Well, we don't know if this key actually is used for decrypting sensitive (or any kind of important) data. It also could be eg. part of a (insecure dumb) method to prevent any server access from outside of their own app. Or plenty other things. ... But still, you're probably right. And I can't help to get amazed at the stupidity of people again and again. – deviantfan Jul 16 '18 at 23:50
  • 2
    (And given that this is a game with billions of downloads... sigh) – deviantfan Jul 16 '18 at 23:54

Deploying a PEM file that is signed by a trusted root CA, even if you self-signed the root CA, is common. I have configured and deployed a public key infrastructure, with hierarchy:

  • root CA
  • intermediate CA
  • server certificate

NextCloud deploys a similar configuration for authenticating in-app updates, which uses a self-signed root CA. As they control the root CA, and subsequently all proceeding signed certificates, with the option to revoke certificates on demand.

The answer, MiTM someone that is using the app yes, under certain conditions. Presuming a web server is deployed using HTTPS without forward secrecy (PFS) and you control the web server's private key used to initiate the key exchange, you could have intercepted the session and key exchange, then use WireShark to decrypt the relevant packets for the key exchange using the server's private key. Then you would have the symmetric decryption key(s) for the session(s).

To harden your app against a viable MITM attack consider:

  • Please notice it is a self signed cert. No PKI was used. – goteguru Jul 18 '18 at 9:50
  • Also notice that it includes the private key. Having a pem file with the public key could be used for key pinning without bothering with a PKI, the real problem is that the private key is included. – AndrolGenhald Jul 18 '18 at 14:42
  • Without a PKI, compromise of the certificate could result in problems long term, it entirely depends on what the certificate is being used for. -- I should also clarify certain criticism my answer has received. A MITM attack is possible under all conditions. However, I was referring to the ability to actively decrypt data via the key exchange, which would not be viable using PFS without modifying traffic (see Diffie-Hellman). Furthermore, this answer is speculative, because it involves broad security aspects, from my interpretation of the question. – safesploit Jul 18 '18 at 14:44
  • @AndrolGenhald PKP is a brilliant idea, just acknowledge the risks of implementing it. The private key is used for signing, otherwise no authentication can be performed. This is why I suggest a PKI with PFS, as authentication requires the corresponding private key, for the certificate (public key). The app for this to be secure need to be run server-side, otherwise, the client-side code needs to encrypt with a public key and send to a centralised server with the private key for decryption. A PEM is not ideal for this, instead, have two files Public Key and Private key. – safesploit Jul 18 '18 at 14:53

It depends on the usage. Since you've posted the certificate we can see it's a self signed certificate with the corresponding private key, valid to Nov 4 12:39:28 2018 GMT. You probably extracted it from the Candy Crush game.

Most possibly it's worthless (you can generate any number of certs like this), unless it is used for something interesting online. If this pair is used for anything, somebody made a mistake. Unless Perfect Forward Secrecy was used in the communication, we don't even need MiTM since we have the private key now. We can decrypt all messages directly (provided we can capture the data of course). Moreover, we could fool the clients with our own server version and do what we want. We have to reverse engineer the software and/or the protocol though.

There is a slight chance it is a uniquely generated pair for your app instance, which is used for identify you at the server. That case attackers now can fake your identity in the Candy Crush game since you have published your private key. I don't think it is the case though, because the Subject field doesn't seems to be unique.

Regarding to your last question, yes it is certainly possible to deploy pem files with the app, since pem is a container format, it doesn't necessarily contain the private key (while the one you posted does). Distributing certificates is perfectly valid, most of the browsers do it.

  • I'm going to actually mitm the game tonight and see if I can use the key to decrypt traffic. I should have just started with that instead of speculating. – Anthony Russell Jul 17 '18 at 19:13
  • Well, it's hardly a server key, but it's your call. – goteguru Jul 18 '18 at 9:51
  • 1
    "We don't even need MiTM since we have the private key now. We can decrypt all messages directly (provided we can capture the data of course)." Note that this is only true if the connection secured by this key doesn't use forward secrecy. – Joseph Sible Jul 23 '18 at 2:24
  • 1
    @JosephSible Yes, that's true. Fixed the statement. Thanks for spotting. – goteguru Jul 23 '18 at 8:49

My assumption is, with the ssl.pem file, I should be able to:

-MiTM someone that is using the app -Feed the pem file to Wireshark -Decrypt and inspect all their traffic.

Is this a realistic attack? Is there something I'm missing?

If this certificate/private key pair are used for the client side of Mutual authentication in TLS then you would still need the server private key to decrypt traffic.

Mutual TLS is where the server authenticates the client after the client authenticates the server. But the traffic is still encrypted using a scheme that relies on the server private key. The private key of the client would be used to sign a challenge to confirm that the client is the certificate holder.

If the entity on the client-side of mutual TLS is an app, then the client private key and certificate need to be embedded somewhere in the app.

  • 1
    note: If the pair is used for client side auth, it must be unique (which doesn't seem to be the case) publishing it completely defeats the purpose. – goteguru Jul 17 '18 at 18:24
  • "Must" or should? Also, it's not clear to me from the post whether or not the data is unique. – hft Jul 18 '18 at 0:07
  • well, how can the same key identify anything? Of course it could identify the software itself, but if anyone can download it, what is the purpose? The pair technically may be unique (as I wrote in the answer) it just doesn't seem to be. If I'd make unique certs for my software instances I'd use unique subject (which is not the case here). I upvoted this answer though for mentioning the mutual auth, which is of course possible. – goteguru Jul 18 '18 at 9:42
  • I got you. I'm just saying that just because a developer should do something the right way doesn't mean they must do it the right way. – hft Jul 19 '18 at 4:10
  • yeah true. Humans are humans. One can find active private keys, database passwords and alike at github after all. Once I myself accidentally committed my crypto exchange access token for ~10 minutes. (No, it's not valid any more, sorry. :) – goteguru Jul 19 '18 at 9:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.