Original

Heartbleed Aftermath: How to Effectively Diagnose Your Affected Services


heart


Since OpenSSL's Heartbleed bug hit the news last Monday, the media has covered the obvious bases: from what it is and what it does to various guides for recovery. However, despite all this, there hasn't been much focus on diagnosing affected services. Therefore, as a good citizen of the devsphere, I dug around for some answers...

Enter Filippo Valdorez's Heartbleed test, a web frontend for a command-line tool that performs attacks and reports if a service is safe or vulnerable. Using it is as simple as inputting the server hostname and clicking the "Go!" button.

The only downside is it's lack of multi-server verification or batch processing capabilities. However thanks to Heartbleed test's underlying command-line and a bit of research, I discovered a fairly straightforward solution.

Installation

The instructions from Heartbleed tool's README assumes that the Go programming language is installed on your system. Here's how to install Go if you are running on OS X:

$ brew install go

After this, you will need to set your GOPATH in order to use the go get command. See below:

$ export GOPATH="$HOME/src/go"

Lastly, ensure that whatever directory you set as your GOPATH exists:

$ mkdir -p $GOPATH

Now you are ready to follow out the instructions from Heartbleed tool's README:

$ go get github.com/FiloSottile/Heartbleed
$ go install github.com/FiloSottile/Heartbleed

Since the GOPATH you set is not in your system's PATH, you'll need to cd into it before running the Heartbleed app:

$ cd $GOPATH
$ bin/Heartbleed
This is a tool for detecting OpenSSL Heartbleed vulnerability (CVE-2014-0160).

Usage:  bin/Heartbleed [flags] server_name[:port]

The default port is 443 (HTTPS).
If a URL is supplied in server_name, it will be parsed to extract the host, but not the protocol.

The following flags are recognized:
  -service="https": Specify a service name to test (using STARTTLS if necessary).
        Besides HTTPS, currently supported services are:
        [ftp smtp pop3 imap]

Diagnosis

Now, with the application installed and ready to run, how do we verify whether an obscure service is affected?

For example, say we admin an OpenVPN server and want to make sure its not affected. To do this (making sure to substitute your server's hostname in for the made up one I use here), execute:

$ bin/Heartbleed vpn1.company.com:1194
2014/04/10 23:33:40 ([]uint8) {
 00000000  02 00 79 68 65 61 72 74  62 6c 65 65 64 2e 66 69  |..yheartbleed.fi|
 00000010  6c 69 70 70 6f 2e 69 6f  59 45 4c 4c 4f 57 20 53  |lippo.ioYELLOW S|
 00000020  55 42 4d 41 52 49 4e 45  d1 ca 95 f8 c8 67 87 d7  |UBMARINE.....g..|
 00000030  81 d1 a9 24 58 8e 66 52  08 1b 25 69 de b3 2e 00  |...$X.fR..%i....|
 00000040  05 00 05 01 00 00 00 00  00 0a 00 08 00 06 00 17  |................|
 00000050  00 18 00 19 00 0b 00 02  01 00 00 0d 00 0a 00 08  |................|
 00000060  04 01 04 03 02 01 02 03  ff 01 00 01 00 a3 8f 47  |...............G|
 00000070  c0 6d 38 25 7a 24 8f 24  5e 01 fa a8 97 fe ee 2b  |.m8%z$.$^......+|
 00000080  30 fe d5 48 38 4a b9 eb  61 5f c3 0d              |0..H8J..a_..|
}

2014/04/10 23:33:40 vpn1.company.com - VULNERABLE

As you can see from the output above, my imaginary company's OpenVPN server is susceptible. Furthermore, seeing the results of this bug make it all the more real. Let's spend some time discussing exactly what the above output means.

Note that there are four columns. The first column contains offsets starting from 0, and is for presentation purposes. The next two columns are the raw bytes that come back from the attack, in hexadecimal format. Lastly, the fourth column is the human readable representation of the second and third columns.

It's worth bringing up that the attack is said to overflow 64 kilobyte chunks of memory. The above output, however, shows only 140 bytes. This is because the author intentionally restricts the payload so as to not leak any sensitive data. Normally considered quite small, 64 kilobytes is a lot of content in this context, and puts the seriousness of this bug into perspective. With 1024 bytes being 1 kilobyte, and 64 kilobytes being returned, the contents could be anything. For this reason alone, the Heartbleed bug truly is the stuff of nightmares for users and administrators alike.

Fixing Your Affected Servers

If you discover one or more affected servers, fixing the problem can vary based on the affected server's function. The Electronic Frontier Foundation has a thorough recovery guide detailing how to update your OpenSSL installation, rekey your servers, and configure Perfect Forward Secrecy. Utilize this guide for fixing these server specific functions.

OpenSSL's Heartbleed bug has definitely thrown a wrench in Internet security. However, we can combat it and identifying affected servers is one way. Hopefully this post can help ease this painstaking but necessary task!


Got questions, suggestions, etc? Keep the conversation going!