How to fix the Heartbleed bug

CSO has compiled the following information on the Heartbleed vulnerability in order to offer a single source to help administrators and security teams understand the issue and fix the problem.

Credit: Heartbleed.com/Thinkstock

After only a few days, the Internet is still buzzing with news surrounding , better known as the Heartbleed vulnerability. CSO has compiled the following information in order to help administrators and security teams understand the issue, determine their risks, and if needed, fix the problem.

Overview:

The Heartbleed bug was fully disclosed to the Internet on April 7, 2014, but the root cause of the problem was introduced to the OpenSSL platform two years-ago.

The name for this bug is a play on words. The media and some vendors have inaccurately reported the issue as malware, which is a description far removed from the truth. Likewise, other inaccurate reports have said that the issue is a problem within the SSL / TLS protocols. Both explanations are false.

The Heartbleed bug exists because of a flaw in the OpenSSL implementation of the TLS/DTLS heartbeat functionality. So this is a problem with server software, not a problem with certificates. The vulnerability itself can be classified as a critical information disclosure issue.

Impact:

In their advisory, the US-CERT outlines the issue perfectly.

OpenSSL versions 1.0.1 through 1.0.1f contain a flaw in its implementation of the TLS/DTLS heartbeat functionality (RFC6520). This flaw allows an attacker to retrieve private memory of an application that uses the vulnerable OpenSSL libssl library in chunks of up to 64k at a time. Note that an attacker can repeatedly leverage the vulnerability to increase the chances that a leaked chunk contains the intended secrets.

If targeted by an attacker, the flaw will yield some, if not all of the following:

SSL private keys, enabling the decryption of traffic if it’s intercepted; however experts have said that an attacker successfully compromising private keys is unlikely.
Usernames and passwords that are submitted to applications and services running on the server. This is the most likely attack vector, but there have been no security incidents linked to it, at least not yet.
Session tokens are also exposed by this flaw, as are cookie values.

Once the vulnerability became public knowledge, many researchers and vendors have worked to examine the total attack surface.

As such, there have been reports that this vulnerability can be used to amplify traffic and trigger a DDoS, and expose application configuration files, including the connection strings were database usernames and passwords are clearly visible.

Scale and Scope (what’s vulnerable):

The researchers who discovered the vulnerability have explained the most important aspects of the vulnerability as it pertains to scope:

Most notable software using OpenSSL are the open source web servers like Apache and nginx. The combined market share of just those two out of the active sites on the Internet was over 66% according to Netcraft's April 2014 Web Server Survey.

Furthermore OpenSSL is used to protect for example email servers (SMTP, POP and IMAP protocols), chat servers (XMPP protocol), virtual private networks (SSL VPNs), network appliances and wide variety of client side software. Fortunately many large consumer sites are saved by their conservative choice of SSL/TLS termination equipment and software.

Ironically smaller and more progressive services or those who have upgraded to latest and best encryption will be affected most. Furthermore OpenSSL is very popular in client software and somewhat popular in networked appliances which have most inertia in getting updates.

The following versions of OpenSSL are vulnerable to this flaw:

OpenSSL v. 1.0.1 - 1.0.1f

The following versions of OpenSSL are NOT vulnerable to this flaw:

OpenSSL v. 1.0.1g (Current release)
OpenSSL v. 1.0.0x
OpenSSL v. 0.9.8x

The following Linux distributions were shipped with vulnerable versions of OpenSSL:

Debian Wheezy (stable)
Ubuntu 12.04.4 LTS
CentOS 6.5
Fedora 18
OpenBSD 5.3
FreeBSD 10.0
NetBSD 5.0.2
OpenSUSE 12.2

The version of OpenSSL can be obtained by using the openssl version -a command. Versions of OpenSSL 1.0.1x that were built before April 7, 2014 are vulnerable.

As explained by the researchers who discovered the flaw:

The vulnerable versions have been out there for over two years now and they have been rapidly adopted by modern operating systems. A major contributing factor has been that TLS versions 1.1 and 1.2 came available with the first vulnerable OpenSSL version (1.0.1) and security community has been pushing the TLS 1.2 due to earlier attacks against TLS (such as the BEAST).

Testing for vulnerability:

In order to determine vulnerability, several services have been deployed that enable organizations to check the status of their servers. The following two services are the most recommended.

https://filippo.io/Heartbleed/

SSLLabs.com

Fixing the problem:

Fixing the problem created by Heartbleed is a multi-step process.

1. Update OpenSSL

For Ubuntu and Debian systems, OpenSSL should be updated by issuing the apt-get update and apt-get install -y libssl1.0.0 openssl commands.

After that, issue lsof -n | grep ssl | grep DEL and restart all listed services.

–

Debian installs can use apt-get update followed by apt-get upgrade.

–

For CentOS use yum clean all && yum update "openssl*".

Issue lsof -n | grep ssl | grep DEL and restart all listed services.

–

Fedora 18 is no longer supported. The following applies to Fedora 19 and 20.

For Fedora 19 x86_64:

yum -y install koji

koji download-build --arch=x86_64 openssl-1.0.1e-37.fc19.1

yum localinstall openssl-1.0.1e-37.fc19.1.x86_64.rpm

–

Fedora 20 x86_64:

yum -y install koji

koji download-build --arch=x86_64 openssl-1.0.1e-37.fc20.1

yum localinstall openssl-1.0.1e-37.fc20.1.x86_64.rpm

Substitute i686 for 32-bit systems, or armv7hl for ARM systems (Fedora 20 only).

–

For OpenBSD, see this document:

https://ftp.openbsd.org/pub/OpenBSD/patches/5.4/common/007_openssl.patch

For FreeBSD, see these documents:

https://svnweb.freebsd.org/base?view=revision&revision=264267

https://svnweb.freebsd.org/base?view=revision&revision=264266

https://svnweb.freebsd.org/base?view=revision&revision=264265

For NetBSD, see this document:

https://mail-index.netbsd.org/current-users/2014/04/09/msg024667.html

If updating OpenSSL isn't an option for some reason, it's possible to work around the vulnerability by reverting to a non-vulnerable version of OpenSSL, or recompile OpenSSL with the -DOPENSSL_NO_HEARTBEATS flag.

2. Revoke and Replace

Once the server has been patched, all of the private keys used by it need to be regenerated. After this is done, SSL certificates need to be revoked and new ones issued using the newly regenerated keys. Be sure to restart the server in order to assure that any live sessions are terminated.

After that, all passwords – for all accounts – should be changed. If anything, this is a good idea simply out of an abundance of caution. In a technical advisory on the issue, Accuvant recommended the following for passwords:

Change passwords for all accounts - this includes the following:

Single sign-on platforms that may have interacted with the host

Appliance web interface logins that may use OpenSSL/Apache

Active directory accounts that may have been used for backend authentication

Additional Resources:

A set of SNORT rules have been released related to this vulnerability. Rapid7 has released guidance on detecting vulnerability via Nexpose, and Metasploit has released a module for Heartbleed.

Vendor Responses