Heartbleed (CVE-2014-0160): An overview of the problem and the resources needed to fix it

After only a few days, the Internet is still buzzing with news surrounding CVE-2014-0160, 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.

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.

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.

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

Copyright 2018 IDG Communications. ABN 14 001 592 650. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of IDG Communications is prohibited.