Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

up vote 61 down vote accepted

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.

share|improve this answer
    
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 9 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 9 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 9 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 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. –  Lekensteyn Apr 16 at 8:04

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!

share|improve this answer
    
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 9 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 9 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 9 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 9 at 20:59
    
You might want to update your link, the diff is somehow empty. I found your module at github.com/rapid7/metasploit-framework/commit/… –  Lekensteyn Apr 9 at 21:00

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.

share|improve this answer
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 at 7:44

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

share|improve this answer
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 at 17:43

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.