Attacks on TLS vulnerabilities: Heartbleed and beyond

Over the past few years, we’ve seen a variety of TLS vulnerabilities steadily surface. In general, we brand each one as “just another TLS vulnerability,” but the intricacies of each are rather distinct, though not horribly convoluted. Let’s walk through a few together.

This is interpreted by the peer roughly as “You just sent me a message. After copying your message into a buffer in memory, I’ll send the first 4,096 bytes of that buffer back to you.”

See the problem? The peer is too trusting of the sender’s heartbeat message. In other words, the sender can lie about the size of the heartbeat message, and the peer will trust the sender. Yes, the first 5 bytes do contain our message, but the following 4,091 bytes contain other data in memory. If we continuously exploit this, extracting 64 KB of data at a time, we’re bound to find something juicy. Lather, rinse, and repeat to grab encryption keys from memory.

What can I do to prevent Heartbleed?

• If you’re using OpenSSL (the vulnerable library), upgrade to at least0.1g.
• Enable Heartbleed signatures on your intrusion protection system (IPS) and everywhere else.
• Install the appropriate patches from your vendors.

The POODLE vulnerability marked the end of SSL 3.0. A poodle is indeed a dog breed, but POODLE stands for “padding oracle on downgraded legacy encryption.” While one barks and requires tender loving care, the other allows a TLS connection to downgrade to SSL 3.0 if the handshake fails, which is trivial for a man-in-the-middle (MitM) to make happen. The downgrade is conceptually simple and works as follows (assume I’m an active MitM between a victim web browser and a server):

• Web browser: Hi, server. Let’s use TLS 1.2.
• MitM: No, try something weaker.
• WB: OK, server, let’s use TLS 1.1.
• MitM: No, try something weaker.
• WB: OK, server, let’s use TLS 1.0.
• MitM: No, try something weaker.
• WB: OK, server, let’s use SSL 3.0.

*Connection is established to the server using SSL 3.0*

At this point, the client and server have agreed on SSL 3.0, both unaware of what just transpired. The client believes that SSL 3.0 is the strongest protocol supported by the server, owing to the TLS 1.0, 1.1, and 1.2 handshakes failing. But the server only ever received the SSL 3.0 handshake (the MitM rejected the former three connections) and therefore assumes SSL 3.0 is the strongest protocol supported by the client! Alas, the connection is made, and we’re subjected to the underlying security of SSL 3.0.

Here’s the problem: Any SSL 3.0 configuration that uses block ciphers is susceptible to a nasty bug, namely the padding oracle, which allows an active adversary to decrypt 1 byte of an encrypted message by making (at most) 256 requests from the victim’s browser. Decrypting a block of data requires it to be sent over and over again­­––which makes session cookies a great target! If you decide to disable all block cipher support (as mentioned, exploiting POODLE does require block ciphers) and use only stream ciphers (e.g., RC4), you’ll end up defenseless against a completely different type of vulnerability. Catch-22! Lather, rinse, and repeat to decrypt sensitive blocks of data.

What can I do to prevent POODLE?

• Disable SSLv3 support on both clients and servers.
• Enable TLS_FALLBACK_SCSV, which prevents a MitM from downgrading connections to SSLv3.
• Install the appropriate patches from your vendors.

2015: FREAK and Logjam

Let’s welcome in 2015 by shifting gears into a quick history lesson. After Alan Turing successfully performed cryptanalysis on Enigma during World War II (cue “The Imitation Game”), providing unparalleled aid to the Allies and resulting in an Axis surrender, the value of cryptography became apparent. In the name of national security, the U.S. government immediately began to regulate encrypted traffic leaving the country. In the 1990s, this equated to forbidding the export of “strong” cryptography.

Enter export cryptography stage left. Enter FREAK and Logjam stage right. At a high level, FREAK and Logjam are conceptually similar. Both involve a MitM intercepting the plaintext “client hello” to the server and modifying it to explicitly request parameters that are brute-forceable (e.g., export cipher suites):

• Client: Hello, server! I’m sending you this list of all the cipher suites that I’m prepared to use.
• MitM: Hehe. I’m going to replace all cipher suites with export RSA or export DHE [for FREAK or Logjam respectively] and forward these to the server. [See “Additional details” below.]
• Server: Wow, I can’t believe this client wants to use weak cryptography. Whatever… *sigh*

Remember, the client hello is sent unsigned in plaintext, so the server has no way of knowing it’s been tampered with by our MitM. The server assumes the export request is genuine. The TLS Protocol does include protections to detect tampering of handshake messages. However, if the attacker can precompute some information, which is possible for export-strength cipher suites—for various reasons discussed below—then the attacker can bypass this tamper detection mechanism.
 

Additional details

For FREAK, the server uses its private key to sign a 512-bit export RSA public key and sends that to the client. In a perfect world, the client would say, “Wait, stop. I didn’t ask for this weak, brute-forceable public key!” and then terminate the connection. But owing to a flaw in some versions of OpenSSL and the Apple Secure Transport implementation, in some cases, this does not happen, and the client can begin performing cryptographic operations using a brute-forceable RSA key. Since most servers that support export-grade cryptography generate the export-strength key once and then reuse it until the server is restarted, the attacker can brute-force this key once and use it to impersonate the server to vulnerable clients.

For Logjam, the server uses its private key to sign weak 512-bit ephemeral Diffie-Hellman parameters and sends them to the client. Unlike FREAK, which is an implementation bug, Logjam is a vulnerability in the TLS Protocol itself. The format of the handshake message containing ephemeral Diffie-Hellman parameters is identical regardless of whether an export-strength cipher suite is chosen. The message itself does not specify the cipher suite for which the parameters were generated. Moreover, the “group” used for Diffie-Hellman parameters is often hard-coded in server implementations, which allows attackers to precompute information that they can use later to attack TLS handshakes. The client can (and modern web browsers currently do) prevent this by refusing to connect to servers that provide DHE parameters smaller than 1,024 bits. This wasn’t previously the case, owing to compatibility issues, alongside the belief that manipulating the server into choosing weak parameters was infeasible.

At this point, the client will begin performing cryptographic operations using either a brute-forceable public RSA key (FREAK) or brute-forceable Diffie-Hellman parameters (Logjam). Either way, the MitM can now recover the TLS session key, complete the TLS handshake with the client, and impersonate the server. Another one bites the dust!

What can I do to prevent FREAK and Logjam?

• On the server, explicitly disable support for export cipher suites.
• Ensure you have the most recent version of your browser installed.
• Install the appropriate patches from your vendors.