What clients are proven to be vulnerable to Heartbleed?

Question

On several pages, it is re-iterated that attackers can obtain up to 64K memory from the server or client that use an OpenSSL implementation vulnerable to Heartbleed (CVE-2014-0160). There are dozens of tools that reveal the bug in server applications.

So far I have not seen a single tool that exploits the bug in client applications. Is it that hard to exploit the bug at clients? Are clients actually vulnerable or not?

Answer 1

As a matter of fact, yes, clients are vulnerable. So far the attention has been focused on servers as they are much more open to exploitation. (Almost) everyone can connect to a public HTTP/SMTP/... server.

This blog describes how the bug actually works (it mentions dtls_process_heartbeat(), but tls_process_heartbeat() is affected in the same way). This function is used both for clients and server applications, so indeed clients should be vulnerable too.

According to RFC 6520, heartbeats should not be sent during handshakes. In practice, OpenSSL accepts heart beats right after the sending a ServerHello (this is what Jared Stafford's ssltest.py does). Upon further testing, I have discovered that servers can abuse clients by sending a Heartbeat right after sending the ServerHello too. It triggers the same bug.

A proof of concept can be found in my repo at https://github.com/Lekensteyn/pacemaker. From its README:

The following clients have been tested against 1.0.1f and leaked memory before the handshake:

• MariaDB 5.5.36
• wget 1.15 (leaks memory of earlier connections and own state)
• curl 7.36.0 (https, FTP/IMAP/POP3/SMTP with --ftp-ssl)
• git 1.9.1 (tested clone / push, leaks not much)
• nginx 1.4.7 (in proxy mode, leaks memory of previous requests)
• links 2.8 (leaks contents of previous visits!)
• KDE 4.12.4 (kioclient, Dolphin, tested https and ftps with kde4-ftps-kio)
• Exim 4.82 (outgoing SMTP)

It has been demonstrated that 64 KiB of memory (65535 bytes) can indeed returned. It has also been demonstrated that clients (wget, KDE Dolphin, ...) can leak data like previous requests possibly containing passwords.

Answer 2

I wrote a Metasploit module to test this, its currently being reviewed, but should hit the master branch relatively soon. The first version is merged into the master branch at this point.

https://github.com/rapid7/metasploit-framework/blob/38a2614fbee1851252462c858057738c06a9f2ab/modules/auxiliary/server/openssl_heartbeat_client_memory.rb

Unlike the server-side attack, you have to implement most of TLS as the heartbeat reply is encrypted against the SSL session key. I tested with wget, curl, and the openssl command-line. One interesting tidbit is that against wget and openssl(1), the attack succeeds regardless of certificate validation. The curl binary requires -k or a valid certificate to keep the session open long enough for the attack to function. Against these relatively synthetic tests, I could reliably leak the TLS session key (AES-128-CBC), but this doesn't provide much since the server knows the same key during the handshake.

EDIT1: Looks like the pacemaker code accomplishes this without doing the full TLS handshake (even better!). I would be interested in any test results folks may have between the implementations. IOW, does pacemaker succeed in cases where the client would otherwise disconnect due to a self-signed certificate?

EDIT2: The method @Lekensteyn uses in pacemaker (send a heartbeat after the Server Hello) is a better approach because CA validation is not an issue. I submitted a new Metasploit PR that defaults to this mode and preserves the TLS negotiation code path using the NEGOTIATE_TLS option (set NEGOTIATE_TLS true for the old mode). Props to @Lekensteyn!

Answer 3

It is possible to exploit the bug in clients. This tester can be used to give out an 'evil' URL to arbitrary clients and see if they take the bait or not. I found 3 top 100 websites (I won't name them here) that fetch URLs using clients that were vulnerable as of 2014-04-09.

Answer 4

If you have an Android device, you can install one of the Heartbleed apps that test for the vulnerability, like this one:

https://play.google.com/store/apps/details?id=com.lookout.heartbleeddetector

I tested this on two Android phones, one with 4.3 and one with 4.4, and both report to be vulnerable, but for both OpenSSL is not used, so all is good....

So everything is OK. Great then, no apps are using OpenSSL. But what if I install an app that does use it? Will I be notified? I guess not!

The 4.4 phone is brand new from Sony, and after first use it downloaded a system update, but I suppose this is not important enough to be fixed?!