MITM Labs/Decrypting HTTPS Traffic by Obtaining Browser SSL Session Info

A supremely evil attack.

This attack utilizes an environment variable (SSLKEYLOGFILE) to obtain private keys for HTTPS traffic.

This will allow ANY captured packets encrypted using ANY SSL key specified by SSLKEYLOGFILE to be decrypted and its plaintext contents inspected at will.

Firefox has disabled SSLKEYLOGFILE in optimized builds, but it still works in developer builds and can even be shivved into an optimized build by including the NSS library.

In Chrome the SSLKEYLOGFILE variable will (should?) work without any issue.

Overview

This page will cover an attack on HTTPS that utilizes a stolen private key to decrypt and sniff HTTPS traffic from a sheep user. Unlike SSLStrip or SSLSniff, this attack requires more information from the sheep (and potentially requires more invasive methods), but is entirely transparent to the sheep if carried out correctly.

Obtaining Private Key

Suppose you wish to eavesdrop on a sheep's HTTPS traffic, and you have physical access to their machine. How might you obtain the private key they use for HTTPS, which would allow you to decrypt all of their HTTPS traffic?

Ultimately we're looking for private keys in either PEM or PKCS12 format. OpenSSL and other online converters can convert private keys among the various formats available.

Sniffing SSL Traffic

In order to sniff HTTPS traffic, we can either sniff remotely or locally.

• If sniffing remotely, carry out a MITM attack, such as ARP Poisoning, with a tool like Bettercap. Once you have made a connection to the sheep, pass all traffic from/to the sheep through a network tap device, and use a standard sniffing tool to dump all the traffic (e.g., tcpdump).
• If sniffing locally, sniff the network device that the browser will be using (or sniff all network devices, if you aren't sure which one). See tips below on filtering to keep this from being an overwhelming amount of data.

The Tcpdump page has more on how to best utilize tcpdump, but here are some tips:

• The more information you can filter, the better - smaller file sizes, easier to exfiltrate, less postprocessing, more targeted
• Rotate pcap files every N minutes or N hours, based on the traffic you're expecting.
• Think ahead to how quickly the pcap files will grow, how much space you have, and how fast you can exfiltrate.

The HTTPS traffic will appear encrypted in the pcap file, but with the sheep's private key, we can decrypt all the HTTPS traffic we want.

Decrypting SSL Traffic with SSL Info

This technique will give us raw SSL private key info in the SSLKEYLOGFILE file. To actually utilize these, we can use two method:

1. Use Wireshark, which has built-in functionality to do this [1]. This is the easiest technique when you have the raw SSL private key info (this technique).

2. Use the SSLDump tool, a command-line tool for capturing and decoding SSL streams given the proper credentials [2]. This is easiest when you have the actual private key .pem file (see MITM Labs/Decrypting HTTPS Traffic with Private Key File page for how to do that).

Tools Required

We'll be using the following tools to illustrate method 1:

• Bettercap
• Tcpdump
• Wireshark

Procedure

Here are the basic steps:

• Carry out a man in the middle attack (in this case, we'll use Bettercap, but anything else will work too) to intercept the target's web traffic
• Capture pcap of web traffic
• Decrypt the HTTPS traffic (live and offline) with SSLDump
• Decrypt the HTTPS traffic (live and offline) with Wireshark

MITM Attack

It is important to note that the SSL keys are ephemeral (per-connection), so the timing of the encrypted pcap packet capture must match the timing of the SSL session info obtained using the SSLKEYLOGFILE method.

If you have remote access to the sheep, you should have remote control over when the action that obtains SSL session information occurs. (There are a lot of different configurations for MITM attacks, so even though you have remote access to the sheep and presumably more info from that side, it is not necessarily practical.)

A good place to start is to assume that you have full control of the sheep. Eavesdrop/MITM the sheep's encrypted connection, on the sheep, and decrypt the resulting encrypted pcap file.

Once you have that working, then move on to including a MITM attack in the mix.

Optional: Start Man in the Middle Attack

I'll run a straightforward man in the middle ARP poisoning attack with Bettercap for this demonstration. You can also use an ICMP attack, or a DHCP attack, or physical attack, or some other attack, to obtain control of sheep's traffic.

For more information about Bettercap, see the Bettercap page.

For more information on how the ARP poisoning attack works, see the ARP Poisoning page.

For more information on how to carry out an ARP poisoning attack with Bettercap, see MITM Labs/Bettercap Over Wifi

Start Capturing Traffic with Wireshark

If it is not already started, start Wireshark and capture on the interface that the web browser will be using (or, all interfaces that it might use). This will actually capture any encrypted traffic passing from the browser through the network interface and off to the internet.

Obtain SSL Session Info from Firefox

NOTE: this will require a developer version of Firefox - as of version 48 you can no longer export SSL information from Firefox to environment variables in optimized builds. (See this stack overflow answer and this mozilla bug.)

NOTE 2: this thread indicates you could simply grab a libssl3 library to add NSS to a non-debug build. This would enable you to use SSLKEYLOGFILE on an optimized, non-debug build.)

Run Firefox from the command line. Specify which file you want Firefox to use to dump out private SSL keys by specifying the SSLKEYLOGFILE variable:

SSLKEYLOGFILE="/temp/thatwaseasy" /Applications/FirefoxDeveloperEdition.app/Contents/MacOS/firefox

Use the browser window that was opened to generate some HTTPS traffic, log into HTTPS sites, etc.

Now the file at /temp/thatwaseasy will contain information that looks like this:

# SSL/TLS secrets log file, generated by NSS
CLIENT_RANDOM 55affa99bbfb5088dfa8aa3edac9b043893c2fe02f5ee700768ee35a34fd97c5 af405e9d3308403df7e76d61b03b15475851e6e5595749a2e17b53b2090d225fc19f07910a1d4ebcf5e9506228b71
CLIENT_RANDOM 1153761194d8a89fd32a72b7aaab17f4134bd1fd3290ba812c72005bd3bcca8f d10652999e4a6164bdc3b5a35120db64d5830d516addb00897883e90e8315956d90684b0cb45a4f94dd29f81afdce
CLIENT_RANDOM 1094ba031312eeffaa1f143d6003933837900a33802629a61c944acb2ca5b1a3 316a891cdf0ca769790b3e40148383960364535c87429f0b1a8c8f059bf7e5d73eb96e3ca48899b53a6622d327bb9
CLIENT_RANDOM 39b57965bd9d53b3484c71c4780c3825d64436c531bf1d81d6dfab27643027b9 60e295b1fae0ed200adba309dcbe52f196e4f1e8fce116ea4a86f4c506c62d8b02a57d80544d0db215e0bd25b473c
CLIENT_RANDOM bce617f1d346bab8537ef956e5d57cab9f966020a0b3c8772ad581c1c2b86f10 4d11a972bf1ca9256a0bc6bfd82e0c44f64434df52e02e00bdae183da92acc831f4ed8f0fa3583d67580b8d38a91d
CLIENT_RANDOM a757f10517b8cc70ebd1dc6ecad743fd7e23887df307ba8d899c3e27310f86b6 50cff7d1624efa7bf4eb89c143a3a2904df1f2d692543ea62e4533b590cc9c8ea32036204fb41bcf8e6a9bd9cadf1
CLIENT_RANDOM 84b8f1a5ef13b275139e7e5d01b7364df854dd5d64b5b9fd5f3784a9094c91d9 88cde6ca6b293471e2d4498b73eca0f41bf896756ef31ba9dcca8f0b381582235224b875196103db9b167e13ebe59
CLIENT_HANDSHAKE_TRAFFIC_SECRET c1a56a6b163ff0c6444c06e9394fa836c0c115e2de26f9ddac169e8bdee4509f f414e0ea02f14cbf3b9168af78cad5c8ca4fd58728a1cde9cb90dc9ebbc2e
SERVER_HANDSHAKE_TRAFFIC_SECRET c1a56a6b163ff0c6444c06e9394fa8f630c115e2de26f9ddac169e8bdee4509f bd94b6d3db895a53e044d85ae275e3a2b3eaf95a44bbbc3352a8c23dfc97e
CLIENT_TRAFFIC_SECRET_0 c1a56a63163ff0c6444c06e9394fa8f6c0c115e2de26f9ddac169e8bdee4509f afad11e14c72d5ade646c3031d74ea387036ec09cdf77015270968323ecda
SERVER_TRAFFIC_SECRET_0 c1a56a63163ff0c6444c06e9394fa8f6c0c115e2de26f9ddac169e8bdee4509f 99f2d876b4e4591900eac18f820b5d887a2e7663126d5b83d57577f374f98
EXPORTER_SECRET c1a56a6b163ff0c6444c03e9394fa8f6c0c115e2de26f9ddac169e8bdee4509f b11283c011f43598da0973e085023f46769de40b0a5104e3998368a34f8af

Inspecting Decrypted Traffic in Wireshark with SSLKEYLOGFILE

Once you're ready to inspect the traffic, stop the network capture (you can use wireshark or tcpdump).

Open Wireshark

Open the pcap file with encrypted traffic

Point Wireshark to the secrets file:

• Open Wireshark
• On Mac click Wireshark > Preferences > Protocols > SSL
• On Windows click Edit > Preferences > Protocols > SSL
• Edit the (Pre) Master Secret Log File Name option to point to /temp/thatwaseasy.

This will allow Wireshark to use the appropriate SSL key to decrypt encrypted packets.

If you see an encrypted packet, its type will be HTTP:

If you click on the packet, the panel at the bottom displaying the header info and hex dump will not be too interesting, since the contents are encrypted, of course:

But if you click the "Decrypted SSL data" tab at the bottom (which only appears if a packet is encrypted and Wireshark has the key needed to decrypt it), you can see the plaintext contents of the encrypted packet:

Decrypting with SSLDump

I have no idea how to get a private key pem file without SSLKEYLOGFILE working.

However, let's move on to the next step, which is what you WOULD do once it's working.

Once we have the private key in a pem file, we can decrypt traffic from the pcap file using the following SSLDump syntax:

ssldump -i eth0 -Ad -k ~/server.pem 

or, if there is HTTPS traffic from multiple hosts and/or we have multiple keys, we can use the SSLDump syntax to filter packets:

ssldump -i eth0 -Ad -k ~/server.pem port 443 and host 192.168.0.7

Decrypting with Wireshark

http://packetpushers.net/using-wireshark-to-decode-ssltls-packets/

Links

Similar concept: Dell computers were shipping with identical private keys, allowing precisely this kind of attack to be carried out against any machine of that make: https://duo.com/assets/pdf/Dude,_You_Got_Dell_d.pdf

In-memory extraction of private keys from SSH, Apache, OpenVPN: http://c0decstuff.blogspot.com/2011/01/in-memory-extraction-of-ssl-private.html

Heartbleed attack to obtain server private keys: http://jarmoc.com/blog/2014/04/16/heartbleeding-private-keys-via-metasploit/