Heartbleed Aftermath: How to Effectively Diagnose Your Affected Services

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.


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:

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

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

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

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


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:

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!