On severalpages, 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 dozensoftools 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?

4 Answers
4

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.

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.

@scuzzy-delta That is more likely to be an Alert. 15 03 03 00 02 02 28 is a Fatal Handshake Failure. I had that when the cipher suite was not supported. You cannot conclude that a server is (in)vulnerable from this.
– LekensteynApr 9 '14 at 17:48

3

In theory, someone can take over your ISPs' DNS server and proxy traffic through his boxes while mining your machine. The NSA might be doing this at US IXPs. if the Google crawler or any other crawler is not patched, one might be able to extract data from Google/Yahoo via their crawlers... Given that everyone is concentrating TLS servers, this might be a very plausible attack vector.
– LmwangiApr 9 '14 at 21:11

Clients on Ubuntu saucy with all updates don't show any vulnerability. However, clients on Ubuntu raring with updates are bleeding.
– HRJApr 16 '14 at 6:32

1

@HRJ 13.04 Raring was EOLed since 27 January 2014 so you might have more to worry about. 12.04 Precise, 12.10 Quantal and 13.10 are still supported and have been fixed. This may be a bit unexpected, but Canonical has lowered the supported cycle from 18 to 9 months starting with Raring.
– LekensteynApr 16 '14 at 8:04

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!

You should try this against those Digi Devices you wrote about a while back. Many of those, and other manufacturers, might use OpenSSL for their VPN and tunnel functionality.
– MToeckerApr 9 '14 at 20:22

1

I reviewed the firmware/memory dumps and SDKs for quite a few of these (Digi & VxWorks mostly) and OpenSSL was rarely used due to memory requirements. The proprietary crypto libs by companies such as Allegro Software and Wind River may have other bugs, but probably not the same as this one. Even still, its worth some serious testing. My $0.02 is that an unreasonable number of DVR and NAS devices are going to be vulnerable due to their reliance on stock Linux/busybox/openssl setups.
– HD MooreApr 9 '14 at 20:33

1

Darn, I was hoping for an obvious ICS angle here. I've run into busybox w/ openssl on a few assessments, probably a good time to run it down. Thanks!
– MToeckerApr 9 '14 at 20:41

@HDMoore pacemaker works reliable on all openssl clients I have tested on (see its README), it does everything before a key exchange or even certificate is hit. You did some nice work! I considered doing this, but as I should be preparing some examinations, I dropped that time-consuming idea ;)
– LekensteynApr 9 '14 at 20:59

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.

I tried this website and it is a bit fishy. It says that is was able to capture the approximately 16 KiB, but when watching s_client output and a packet capture, I see continues requests. I manually aborted after 5 MiB of captured information. Where is their privacy policy?
– LekensteynApr 10 '14 at 7:44

Looking at the source code of this program, it searches the library file for patterns (like grep -F 1.0.1a /system/lib/libssl.so). Not an entirely reliable method as a patch might have been applied to fix the bug. A more reliable approach would be actually test for the bug such as done by pacemaker.
– LekensteynMay 26 '14 at 17:43