On April 7, 2014, a vulnerability in the OpenSSL cryptographic library was announced to the Internet community. Aptly labeled as the Heartbleed bug, this vulnerability affects OpenSSL versions 1.0.1 through 1.0.1f (inclusive). The Heartbleed bug is not a flaw in the SSL or TLS protocols; rather, it is a flaw in the OpenSSL implementation of the TLS/DTLS heartbeat functionality. The flaw is not related or introduced by publicly trusted certificates and is instead a problem with server software.
Heartbleed Bug Discovery
The Heartbleed bug was uncovered by a group of security engineers from Codenomicon and Neel Mehta from Google Security. According to The Heartbleed Bug website hosted by Codenomicon:
“The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).
The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.”
Software bugs are part of every software release, and most software updates or new versions of software include bug fixes. The features of the Heartbleed bug that make it unique include:
- Any Heartbleed-based attacks are not readily traceable. Because the problem has existed for two years, most server operators using a vulnerable version of OpenSSL likely don’t have enough logs/monitoring to determine whether a site was compromised.
- The potential impact of the Heartbleed bug vulnerability is difficult to measure. The Heartbleed bug was included in the 1.0.1 release of OpenSSL on March 14, 2012 and was included in each additional release through the OpenSSL 1.0.1f release.
- The Heartbleed attack does not rely on other vulnerabilities to compromise a site. Often, attacks necessitate that the attacker first exploit a weak security practice to get a foothold in a system.
- The internet and security communities pushed OpenSSL 1.0.1 and subsequent releases because they included TLS 1.1 and 1.2 which contained fixes for vulnerabilities to other attacks in TLS 1.0, such as the BEAST (Browser Exploit Against SSL/TLS) attack.
OpenSSL version 1.0.1 through 1.0.1f and 1.0.2-beta1 are vulnerable to the Heartbleed Bug attack. The OpenSSL version 1.0.1g released yesterday fixes the Heartbleed Bug. Note that earlier versions of OpenSSL branches 1.0.0 and 0.9.8 do not include the Heartbleed Bug vulnerability. The 1.0.2-beta2 version will contain the fix that is included in OpenSSL version 1.0.1g.
Heartbleed Bug Impact
If the servers in your SSL environment do not use OpenSSL, if your servers use OpenSSL 1.0.0 or earlier, if your servers do not use OpenSSL 1.0.2-beta1, or if your servers are compiled without the heartbeat extension enabled, then your environment is not vulnerable to the Heartbleed Bug attack.
However, if your servers are running an OpenSSL version 1.0.1 through 1.0.1f with the heartbeat extension enabled, then your environment is vulnerable to a Heartbleed Bug attack. Although no Heartbleed Bug attacks have been documented, it is impossible to know if the Heartbleed Bug vulnerability has been exploited because the attack does not leave a trace.
Solutions
If your servers are running OpenSSL versions 1.0.1 through 1.0.1f with the heartbeat extension enabled, you should take the following actions as soon and as quickly as possible to mitigate any possible damage:
- Upgrade your server to the latest version of OpenSSL (version 1.0.1g or later).
Check your package manager for an updated OpenSSL package and install it.
If you do not have an updated OpenSSL package, contact your Service Provider to obtain the latest version of OpenSSL.
- Rekey, reissue, and then revoke all certificates used with the vulnerable version of OpenSSL.
To Upgrade Your Server
Check your package manager for an updated OpenSSL package and install it. If you do not have an updated OpenSSL package, contact your Service Provider to obtain the latest version of OpenSSL and install it.
Workarounds
Only use these workarounds if you cannot upgrade to the latest version of OpenSSL. If you are unable to upgrade to the latest OpenSSL version, do one of the following:
- Rollback to OpenSSL version 1.0.0 or earlier.
- Recompile OpenSSL with the OPENSSL_NO_HEARTBEATS flag.
To Rekey Your Certificates
Once the server has been patched, we recommend that you replace your certificate with a new one using a new keypair, an operation commonly referred to as a ‘rekey’. To do this, you will need to generate a new CSR and submit it to your CA so that they can reissue the certificate. Your CA can help you generate the CSR and provide additional information about rekeying your certificate. You should confirm with your CA that the old certificate is revoked once you’ve installed the new one on your server.
Although the chance of an attacker obtaining a private key through heartbleed is unlikely, rekeying is a good precaution given the sensitive nature of the information. We encourage any server operator affected by the vulnerability to consult with their CA if they have questions about the potential impact and risks.
Other Suggestions
In addition to replacing affected private keys, server operators should encourage users to change any passwords possibly leaked through the vulnerability. Periodically changing passwords is a good security practice, and this vulnerability gives system administrators a launching point to affect change within their infrastructure. Of course, passwords should be changed after the vulnerability is patched on the server to avoid leaking the new password.
We encourage all users to use different passwords for various sites. Using multiple passwords ensures that a compromise of account with one site will not lead to a compromise of multiple accounts associated with the same email or username.
Summary
Again, this vulnerability is not a flaw related to the protocols or the use of digital certificates. Instead, the flaw is a result of a bug in the open source program. Although this is a severe failure by the software developers to detect a major vulnerability, CASC encourages industry participants to focus on ways to prevent a reoccurrence of similar problems rather than blamestorming. The CASC members fully support the initiatives to remedy this vulnerability and look forward to working with the non-CA community in ensuring a safe and secure Internet.
