Heartbleed (CVE-2014-0160): An overview of the problem and the resources needed to fix it
CSO - 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.
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.
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.