The Heartbleed Bug is a dangerous vulnerability found in OpenSSL. It potentially allows the compromise of encrypted information, that under normal conditions is secured by SSL/TLS. 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 following versions of OpenSSL are/are NOT vulnerable to the Heartbleed bug:
- 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; and
- OpenSSL 0.9.8 branch is NOT vulnerable.
I won’t go into the technical details of this vulnerability, since that has been done en masse. If you are looking for that level of information, I recommend the following analyses:
- Heartbleed Bug
- Diagnosis of the OpenSSL Heartbleed Bug
- Everything you need to know about [Heartbleed]
There are several misconceptions about Heartbleed, with common ones focusing on end-servers running Microsoft IIS and not evaluating upstream technologies like reverse-proxies, load-balancers, or having users change passwords before a fix has been implemented.
What I do want to discuss is a recommended approach for organizations dealing with the “Heartburn of Heartbleed.” We’ve had numerous clients reach out to us asking for assistance in several areas; identification, remediation, and working with security technology vendors to determine when their fixes will be ready. Here is what we recommend for each of these stages:
There’s been an influx of tools and scripts made available to identify the Heartbleed vulnerability. Below are ones that meet specific use cases:
- https://svn.nmap.org/nmap/scripts/ssl-heartbleed.nse (Nmap)
- http://www.exploit-db.com/exploits/32764/ (Python)
Vulnerability Management Tools
This is where the heartburn starts. Hopefully, your organization maintains a Threat Management Program and you have already addressed your high-risk assets. If not, here is a triage approach:
- Patch perimeter systems first, then critical internal systems, then production systems, and then test/dev systems;
- If a patch or configuration fix is not yet available, <insert heartburn here>. Taking a proactive approach, you can implement a reverse-proxy (Load Balancer) that is NOT vulnerable, or can be configured as such, to terminate the encrypted connections, thereby eliminating risk to your web and application servers. If you prefer a passive approach, you can implement signatures on IDS/IPS solutions, but I do NOT recommend relying on these. Snort signatures are available here. Bro Heartbleed module here;
- Regenerate all SSL certificates with new private keys;
- Replace all SSL certificates with newly generated certificates;
- Revoke all old SSL certificates;
- Force all accounts on affected systems to expire; and
- Communicate to account users the necessity for the password resets. CloudPassage did a good job of this; here is a link to their blog post.
Security Technology Vendors
This is where the heartburn can reach extreme levels. Some vendors have done a great job implementing fixes as soon as updates to OpenSSL were available, however, others have been less than forthcoming with their remediation approach and timelines. These are the solutions that you rely on to protect your organization and their internal failure to identify and remediate vulnerabilities in core components of their solutions in a timely manner has left you vulnerable. If this is the case, I recommend emailing your vendor representatives and letting them know you need this information ASAP. If you have formed an internal task force to deal with Heartbleed, it may be worth mentioning this to the vendor representative, and suggest that being “last” to remediate amongst your vendors is probably a bad idea.
If you utilize a Value Added Reseller (VAR), for example GuidePoint Security, I recommend reaching out to your Account Executive (AE) and asking for assistance. Provide your AE a list of all technology vendors you need assistance with, as you probably own more technologies than you have purchased through them. This is an area where VARs can show some of their “Value.”
It is my sincerest hope that organizations embrace this opportunity to take a fresh look at how they are dealing with a number of areas within their Information Security Program. Particularly, I believe Heartbleed has forced organizations to look at:
- Threat Management
- Vulnerability Management
- Patch Management
- Public Key Infrastructure (PKI)
- SSL Decryption / Visibility Practices
GuidePoint Security can assist your organization in building and maturing these components of your Information Security program, as well as help procure, architect, implement, and optimize security technologies to support them (Hey, I have to get a shameless plug in somewhere, right?).
*** Updated on 4/10/14 @ 13:49 to include vulnerable/NOT vulnerable versions of OpenSSL, replace the python script with one that does not have false positives and clarify my statement on identifying vulnerabilities in core components of security technologies. ***