Is it possible to decrypt an SSL connection (short of bruteforcing)?

Question

I'm trying to reverse-engineer a protocol (it's for a game whose server's are closing soon). I have two things: 1) the binary for the program 2) a packet dump from Wireshark (I am still able to get another dump, if needed). Now, the protocol, from what I can see from the dumps, is TLS/SSL (not sure which one) encrypted. I am aware that Wireshark has the capabilities to decrypt these packets, given that I have the required keys.. but how in the world do I extract the keys out of the binary?

tl;dr Can I access plaintext SSL given the originating binary?

Answer 1

If you have access to the binary while it is running, it is entirely possible to extract the keys you need to decrypt the SSL/TLS session even with perfect forward secrecy. There is a 48-byte secret, called the master secret, which is shared by both sides and used to generate the session keys for the connection.

If the application uses the standard Win32 API to make the SSL connection, the point to intercept the key generation is inside lsass.exe, at:

Caller:  ncrypt!_Tls1ComputeMasterKey@32+0x57 
EIP:     ncrypt!_PRF@40+0x11a

More information can be found in my answer to "Decryping TLS packets between Windows 8 apps and Azure".

More generally, I have (with several excellent co-authors) recently developed techniques for scanning all memory accesses for interesting data such as SSL/TLS keys. A paper on this ("Tappan Zee (North) Bridge: Mining Memory Accesses for Introspection") has been published at CCS, and the software to do it is available on github: PANDA/TZB. Particularly take a look at the keyfind plugin, which takes a sample (encrypted) packet and scans memory accesses for TLS master secrets.

The procedure for finding the place where TLS master key generation happens with a new application is:

1. Use PANDA to create a recording of the app making an encrypted connection, and save a packet capture (in the QEMU monitor, begin_record <session_name>, run the app, then end_record <session_name>.
2. Run scripts/list_enc.py on the packet capture to extract the information needed by the keyfind plugin. Place this information in keyfind_config.txt.
3. Run a replay of the session (begin_replay <session_name> in the QEMU monitor) with -panda-plugin x86_64-softmmu/panda_plugins/panda_keyfind.so specified on the command line. After a (very) long time, it will spit out the code locations where a matching TLS key was read or written to key_matches.txt.

The documentation is pretty sketchy at the moment, but looking at the source should resolve any questions you have (and feel free to ask for clarification here!).

For more information on using panda for this see: here

Answer 2

Properly implemented SSL traffic has a property of forward secrecy. Which means that you can't decrypt it even if you have the whole packet dump and required private keys. As Brendan Dolan-Gavitt points out in his answer, you need access to the binary while it's running to do that.

What you can try to do is set up SSL mitm using something like ettercap. Which might be a bit involved and might not work depending on the SSL implementation.

Now, not a direct answer to your question, but it might help you achieve what you want:

Another thing you could to, since your goal is to analyze the underlying protocol is to make hooks on the higher level. I have use oSpy before to do similar work.

oSpy is a tool which aids in reverse-engineering software running on the Windows platform. With the amount of proprietary systems that exist today (synchronization protocols, instant messaging, etc.), the amount of work required to keep up when developing interoperable solutions will quickly become a big burden when limited to traditional techniques. However, when the sniffing is done on the API level it allows a much more fine-grained view of what's going on.

oSpy works by attaching to the process whose traffic you want to analyze and then monitor certain APIs.