Reverse Heartbleed Testing

Published: 2014-04-13. Last Updated: 2014-04-13 13:01:19 UTC
by Kevin Shortt (Version: 1)
4 comment(s)

I wanted to know if the tools/software I execute regularly are vulnerable to scraping my system memory.  Now the reverse heartbleed scenario is very possible, but the likelihood seems to be much more of a non-issue.  

Seeing is still believing in my book.  So I set out to see what the interweb world was doing to test this out.  There are some very reputable services/organizations out there offering up a fresh url to the reverse heartbleed and others offering to 'test' a given url.   These are a black box.  Trust is hard to earn at times, especially when you are dealing with an exploit like this one.  I wanted to see source code, or at least pseudocode so I could craft my own.  I found a script out there called Pacemaker [1] that was written and provided by Peter Wu.  I liked it because it was transparent, simple, and it can be used exclusively under my control (the ultimate first step of developing trust).

So simple, I was able to review it for harm and function, and cut and paste it into vi.  Escape, write, quit, and I was off and running.   Basically it works like a simple webserver, very simple.  The script is executed and listens on port 4433.  You point your client software at it with a localhost url and the server script reports on STDOUT what it finds.  

I did not have any vulnerable client software readily available to give a whirl, but I did try all my curl and wget installs that I use regularly.   I also hit it with Chrome and Safari to see the error messages.

Here is what I tested with it.

wget 1.11.4:  

Connection from: 10.0.0.11:60401
Unable to check for vulnerability: SSL 2.0 clients cannot be tested
 
curl 7.30.0 (x86_64-apple-darwin13.0) libcurl/7.30.0 SecureTransport zlib/1.2.5:
 
Connection from: 10.0.0.11:60418
Got Alert, level=Fatal, description=40
Not vulnerable! (Heartbeats disabled or not OpenSSL)
 
curl 7.24.0 (x86_64-apple-darwin12.0) libcurl/7.24.0 OpenSSL/0.9.8y zlib/1.2.5:
 
Connection from: 127.0.0.1:59451
Possibly not vulnerable
 
Chrome 34.0.1847.116:

Connection from: 127.0.0.1:59490
Got Alert, level=Fatal, description=47
Not vulnerable! (Heartbeats disabled or not OpenSSL)
 

I am interested in seeing more output from known vulnerable client software.  Feel free to give this a ride and share your results.  If I get a chance to spin out a new VM with some vulnerable OpenSSL on it today, then I will share my experiences too.

 

[1]   https://github.com/Lekensteyn/pacemaker


-Kevin
--
ISC Handler on Duty

4 comment(s)

Comments

The client software scene is much more diverse....
While you have some exceptions such as curl/wget, VPN clients, perhaps some FTP LDAP and E-mail clients, which may use OpenSSL.

Most of the major web browsers do not.

Firefox, Chrome, OpenOffice, Evolution, Pidgin, 389 directory services, various Java products = LibNSS
Internet Explorer = Windows CryptoAPI
Opera = [none of the above]
I have try directly with openssl client like:

openssl s_client -connect 127.0.0.1:4433

but imho don't works !
Did you get the following (or something like it) as a response to 'openssl s_client -connect 127.0.0.1:4433' ?

CONNECTED(00000003)
58872:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake failure:/SourceCache/OpenSSL098/OpenSSL098-47.2/src/ssl/s23_lib.c:182:
Got a hit within Cygwin.

curl 7.29.0 (i686-pc-cygwin) libcurl/7.29.0 OpenSSL/1.0.1e zlib/1.2.8 libidn/1.26 libssh2/1.4.2
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp scp sftp smtp smtps telnet tftp
Features: Debug GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP Metalink

Diary Archives