73

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?

Community
  • 1
Lekensteyn
  • 5,898
  • 5
  • 37
  • 62
  • How would you test the tool in the wild on "real" servers to make sure it's working? Is it actually legal to do the exploit in your district? – Pacerier May 04 '15 at 23:25
  • @Pacerier You can set up a lab environment (using virtual machines for example). Then there is no question of trespassing which may be illegal. – Lekensteyn May 04 '15 at 23:39

4 Answers4

66

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.

Lekensteyn
  • 5,898
  • 5
  • 37
  • 62
  • Any return from the client indicates it is vulnerable, correct? Like: Connection from: 127.0.0.1:53459 Client returned 7 (0x7) bytes – scuzzy-delta Apr 09 '14 at 17:16
  • @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. – Lekensteyn Apr 09 '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. – Lmwangi Apr 09 '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. – HRJ Apr 16 '14 at 06:32
  • 1
    @HRJ [13.04 Raring was EOLed since 27 January 2014](https://wiki.ubuntu.com/Releases) 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. – Lekensteyn Apr 16 '14 at 08:04
  • 64KiB is closer to 65535b not 65565b – Snowbody May 06 '14 at 21:03
  • @Snowbody Good catch, corrected and updated with latest README. – Lekensteyn May 06 '14 at 22:09
26

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!

HD Moore
  • 407
  • 3
  • 4
  • 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. – MToecker Apr 09 '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 Moore Apr 09 '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! – MToecker Apr 09 '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 ;) – Lekensteyn Apr 09 '14 at 20:59
  • You might want to update your link, the diff is somehow empty. I found your module at https://github.com/rapid7/metasploit-framework/commit/f56f34fb69373984ee58ec44b84a1d470186421c – Lekensteyn Apr 09 '14 at 21:00
  • @Lekensteyn Thanks! I just sent the team an update that switches between your mode (heartbeat after Server Hello) and the full TLS negotiation. Ill update the link once the new PR is up. I did notice that the amount of interesting data leaked changes between the modes (more after TLS). It might be worth hacking the server-side PoCs to do some interesting app-level stuff before sending the TLS heartbeat. – HD Moore Apr 09 '14 at 21:26
  • @HDMoore The advantage of your approach is that it may be more likely to get hand of client certificates if those were sent. Your implementation is exactly what https://github.com/Lekensteyn/pacemaker/issues/1 was about. – Lekensteyn Apr 09 '14 at 21:27
8

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.

Brad
  • 181
  • 2
  • 5
    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? – Lekensteyn Apr 10 '14 at 07:44
0

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....

Everything is OK!

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?!

SPRBRN
  • 7,379
  • 6
  • 33
  • 37
  • 2
    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. – Lekensteyn May 26 '14 at 17:43