What is the security alert?
The Computer Emergency Response Team (CERT), based at Carnegie Mellon, has issued a vulnerability note (VU720951) relating to OpenSSL 1.0.1. The vulnerability, in the TLS heartbeat code, allows the attacker to read a 64K chunk of the private memory of the process using the SSL library. The attacker my repeat the attack to retrieve as many 64K chunks as necessary to disclose private information such as the server’s private key or the keys used to protect user login passwords.
OpenSSL is a widely used open source cryptography library. Many websites using open source technology such as Apache use OpenSSL for cryptography support. Note that any open source package that support SSL/TLS, including IMAP, SMTP, POP, is potentially vulnerable, not just web servers.
The vulnerability has also been found in a variety of network security products, including Cisco, Juniper, FortiGuard, F5 and others.
Note that Microsoft has their own cryptographic libraries, so that a pure Microsoft implementation, (for example, IIS, Exchange, TMG) is immune to this issue.
What is the impact?
According the CERT advisory, the ability to read the server process’s private memory exposes data including:
- Primary key material (secret keys)
- Secondary key material (user names and passwords used by vulnerable services)
- Protected content (sensitive data used by vulnerable services)
- Collateral (memory addresses and content that can be leveraged to bypass exploit mitigations)
If a website or other service is vulnerable you MUST assume that its private key is compromised and the site cannot be trusted until it has both installed the software fix AND revoked and reissued its server certificates and keys. Even if the server is patched, if the private key is compromised all traffic is easily decrypted. Assume that any passwords to that web site are known.
If a piece of network equipment, such as a router, load balancer, firewall, or switch is vulnerable then traffic to and from its web management interface is vulnerable, including login credentials for the equipment. While the vulnerability in network equipment will not allow encrypted traffic transiting through it to be decrypted, it gives the attacker a powerful jumping off point to get inside your network.
Which versions of OpenSSL are vulnerable?
Here is the data on the versions of OpenSSL that are in common use:
- OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
- OpenSSL 1.0.1g is NOT vulnerable
- OpenSSL 1.0.0 branch is NOT vulnerable
- OpenSSL 0.9.8 branch is NOT vulnerable
Note that OpenSSL 1.0.1 was widely released in March, 2012, so this vulnerability has been in the wild for about two years. Netcraft estimated that on 4/8/2014, the day the fix was released, about 17% of all SSL web servers with trusted certificates were vulnerable.
Most servers get OpenSSL as part of their operating system distribution. The following openly available OS distributions shipped with vulnerable versions and must be patched (see below):
- Debian Wheezy (stable), OpenSSL 1.0.1e-2+deb7u4
- Ubuntu 12.04.4 LTS, OpenSSL 1.0.1-4ubuntu5.11
- CentOS 6.5, OpenSSL 1.0.1e-15
- Fedora 18, OpenSSL 1.0.1e-4
- OpenBSD 5.3 (OpenSSL 1.0.1c 10 May 2012) and 5.4 (OpenSSL 1.0.1c 10 May 2012)
- FreeBSD 10.0 - OpenSSL 1.0.1e 11 Feb 2013
- NetBSD 5.0.2 (OpenSSL 1.0.1e)
- OpenSUSE 12.2 (OpenSSL 1.0.1c)
Vendor distributions, such as Red Hat or SUSE may have similar status to the open editions with the same version number, but you should check with your vendor.
Is there an active attack on this vulnerability?
Nobody is sure about this, so you have to assume there is one. Exploit tools are now widely available, but attacks leave no fingerprints on the attacked server, so there is no way to know if a vulnerable server was attacked, unless derived data (such as user passwords or credit card numbers) are then used.
How do I check and remediate my server?
If you are running Microsoft IIS and/or Exchange then you are not vulnerable. Microsoft has their own cryptographic libraries.
If you are running an open source web server or mail server, such as Apache, Tomcat, Postfix, Sendmail, Cyrus IMAP, etc, then you are vulnerable if you have a vulnerable version of the OpenSSL shared libraries installed. If you compiled OpenSSL from source code, run “openssl version” from a shell and note whether or not you are running a vulnerable version. If you receive OpenSSL as part of your operating system distribution, then you must check with your OS vendor to see if your release is vulnerable and how to update it.
If you are running a vulnerable version, update it immediately.
Once you have updated your OpenSSL libraries, you must revoke and reissue all server certificates, with newly generated key pairs. This is necessary because you must assume that the server’s private keys were compromised.
Once the server is upgraded and rekeyed, you should notify your users to change their passwords. If you can expire them to force the change, do so.
If your site handles any kind of personal data subject to privacy regulations, such as GLB, PCI-DSS, HIPAA, HITECH, or state breach notification laws, you should assess your exposure and consult with legal counsel about your notification obligations.
I'm also a person. How do I protect my data?
You can test the current Heartbleed vulnerability status of a web site with a tool provided by Filippo Ansorda, one of the security researches who has worked on Heartbleed, to see if the site is currently vulnerable. Qualys’s SSL Project Server Test does a more complete configuration audit of a webserver that includes a check for Heartbleed.
If a site you use is vulnerable to the Heartbleed attack, don’t use it until the site has been repaired and issued a new certificate. Once the owner of the site has fixed it, and hopefully notified you, change your password.
Note that almost all Yahoo! web properties were vulnerable, but have now been fixed. You should change your Yahoo! passwords immediately. This is also true for Dropbox, Box, Google, Facebook, Instagram, and Tumblr. Apple and Microsoft have not been vulnerable.
By and large, it looks like the major banking sites were not vulnerable. You should change your passwords on these sites if you reused passwords from vulnerable sites. Keep an eye on your bank and credit card accounts for a while, in case account information was disclosed from a vulnerable site.
This brings us to another best practice. Do NOT reuse passwords on multiple sites. Hackers check to see what else any password they get will open up for them. This greatly increases your risk from an attack on any one site with a common password.
Where is the best information on the web?
The security researchers working on this vulnerability have set up a web site, http://heartbleed.com/.
The OpenSSL project, http://www.openssl.org, has up to date information on OpenSSL.
CERT’s vulnerability notice http://www.kb.cert.org/vuls/id/720951 is being updated as facts develop, so that’s a good place to check.
Mashable has a terrific site with a summary of the status of a whole lot of web sites and another one for network devices.